How to Build an App with AI & Get It on the App Store (No Xcode)

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Primo로 Xcode를 직접 다루지 않고 AI 앱 제작부터 스토어 제출 준비와 TestFlight 실기기 설치까지 진행할 수 있지만, 공개 App Store 출시 완료는 영상에서 확인되지 않는다.

📌 핵심 요점

1. 발표자는 AI 앱 개발의 병목을 코드 생성보다 배포 과정에서 찾는다. 작동하는 코드가 있어도 서명된 빌드, 스토어 자료, 정책에 맞는 정보가 필요하다.
2. Primo는 iOS·Android용 Flutter 앱을 생성하는 도구로 소개된다. 발표자는 네이티브 바이너리 생성과 모바일 배포 지원을 주요 차별점으로 평가한다.
3. 운동 기록 앱에 세트·반복 횟수 입력, 휴식 타이머, 운동별 이력, 최근 3회 목표 달성 시 중량 증가 제안을 구현했다. 모든 운동에 90초로 적용되던 타이머는 자연어 피드백으로 수정했다.
4. 브라우저 에뮬레이터로 화면을 점검하고, 스토어 소개문·스크린샷 등을 생성한 뒤 제출 전 감사를 실행했다. 감사에서 발견된 문제는 채팅과 수정 기능으로 처리했다.
5. App Store Connect의 API 키와 관련 식별자를 입력해 iOS 빌드를 생성하고, TestFlight를 통해 실제 iPhone에서 앱을 실행했다. Android 빌드 생성도 진행했지만 공개 스토어 승인 결과는 제시하지 않았다.

🧩 배경과 문제 정의

이 영상은 AI로 만든 모바일 앱이 노트북 안에 머무르는 이유를 배포 단계에서 찾는다. 발표자는 이전 프로젝트에서 메타데이터 불일치로 거절을 반복하며 작동하는 앱을 약 3주 동안 출시하지 못했다고 설명한다. 코드 이후에도 서명 빌드, 개발자 계정, 인증 관련 설정, 기기별 스크린샷, 개인정보 및 스토어 정보 준비가 필요하다는 문제의식이다.

이를 확인하기 위해 Primo로 운동 기록 앱을 만들고, 맞춤 로직 수정부터 기기별 화면 점검, 스토어 자료 생성, 제출 전 감사, TestFlight 실기기 실행까지 시연한다. 할인 코드가 포함된 제품 소개 영상이며, 실제로 확인되는 배포 결과는 iPhone에서의 TestFlight 실행이다.

🕒 시간순 섹션별 상세정리

1. 코드가 있어도 출시하지 못하는 이유

• Primo로 만든 운동 기록 앱을 소개하며 iOS·Android에서 네이티브로 실행된다고 설명하고, 할인 코드를 안내한다. [00:33]
• 발표자는 코드 생성보다 이후 작업이 어렵다고 주장한다. 서명 빌드와 개발자 계정·프로비저닝·인증서·번들 ID, 스토어별 스크린샷과 개인정보·연령·메타데이터 준비를 열거한다. [01:37]
• 이전 앱이 메타데이터 문제로 약 3주 동안 출시되지 못한 경험을 설명하며, 작동하는 코드를 실제 휴대전화 설치로 연결하는 과정이 핵심 문제라고 정리한다. [02:07]

2. Primo와 네이티브 Flutter 방식

• Primo를 iOS·Android용 Flutter 앱을 생성하는 AI 빌더로 소개하고, 웹 래퍼나 네이티브 셸 안의 웹 앱과 구분한다. [02:35]
• 발표자는 네이티브 방식의 의미를 성능, 카메라·알림 같은 API 처리, 스토어 심사 관점에서 설명하고 실제 컴파일된 바이너리를 강조한다. [03:09]
• 개발팀의 오랜 모바일 앱 경험과 기업공개 이력을 소개하며, 스토어 제출의 어려움을 아는 팀이라는 평가를 덧붙인다. 해당 이력은 발표자의 설명으로 드러난다. [03:44]

3. 운동 앱 생성과 맞춤 규칙 수정

• 세트·반복 횟수 기록, 세트 사이 휴식 타이머, 운동별 이력, 최근 3회 목표 달성 시 중량 증가 제안, 생성형 아이콘과 일러스트를 요청한다. [04:21]
• 홈·운동 진행·이력 화면의 일관성을 확인하고, 최근 3회 기록을 바탕으로 중량 증가를 제안하는 조건부 로직을 보여준다. 예시 화면에는 20kg으로 평균 10회를 수행했다는 안내가 나타난다. [05:35]
• 모든 운동의 휴식 시간이 90초로 설정된 문제를 자연어로 지적해 운동 유형에 따라 달라지도록 수정한다. 발표자는 만족할 결과까지 피드백과 재생성을 반복한 시간이 약 5분이었다고 보여준다. [06:05]

4. 기기별 점검과 스토어 자료 생성

• 브라우저에서 약 30개 에뮬레이터를 제공한다고 보여준다. 작은 iPhone 화면에서 운동 기록이 잘리지 않는지, 태블릿에서 그림이 어색하게 늘어나지 않는지 확인한다. [06:45]
• 에뮬레이터를 사용하려면 먼저 빌드를 생성해야 한다고 안내하며, Android와 iOS의 빌드 생성 메뉴를 보여준다. [07:00]
• 웹 게시로 테스트 URL을 만든 뒤 Google Play·App Store용 자료를 생성한다. 아이콘, 제목, 설명, 키워드, 스크린샷, 피처 그래픽을 살펴보고 재생성과 다운로드 기능을 보여준다. [08:04]

5. 제출 전 감사와 TestFlight 빌드

• 두 스토어의 가이드라인을 기준으로 제출 전 검사를 실행한다. 발표자는 심사 거절 후 문제를 알게 되는 대신 준비 단계에서 발견하는 데 의미가 있다고 보여준다. [08:41]
• 감사가 잠재적인 승인 장애를 찾아내며, App Store 쪽에는 중요하다고 설명한 문제 2개가 나타난다. 발견 내용을 채팅에 붙여 넣거나 수정 기능을 사용한 뒤 문제가 해결됐다고 드러낸다. [09:34]
• IPA 빌드를 선택하고 App Store Connect의 API 키와 관련 식별자를 입력한다. Android 빌드도 생성하면서 iOS 빌드 완료와 TestFlight 등록을 확인한다. [09:54]

6. 실제 iPhone 실행과 도구 선택 기준

• iPhone의 TestFlight에서 앱을 열고 운동을 시작해 벤치프레스 항목을 추가한다. 제작한 앱이 실제 기기에서 작동하는 모습을 보여준다. [10:23]
• 수동 인증 설정과 스크린샷 준비에 걸리는 시간을 자신의 과거 경험과 비교한다. AI 빌더 선택 기준을 코드 생성 속도보다 서명된 앱의 실기기 설치와 스토어 심사 준비에 두라고 제안한다. [11:35]
• 할인 코드와 링크를 다시 안내하고 댓글 질문 및 구독을 요청하며 마무리한다. 공개 스토어 승인이나 출시 완료 화면은 추가로 제시하지 않는다. [11:58]

🧾 결론

• AI 앱 빌더는 첫 화면을 만드는 속도뿐 아니라 빌드·검증·제출 준비·실기기 설치까지 이어지는 흐름으로 평가할 필요가 있다.
• 이번 시연은 자연어로 맞춤 로직을 만들고 수정하는 과정과 배포 준비 기능을 함께 보여준다.
• 스토어 자료 생성과 제출 전 감사는 준비 작업을 줄이는 수단이며, 최종 심사 통과 여부는 별도로 확인해야 한다.
• 영상에서 확인되는 도달점은 TestFlight를 통한 iPhone 실행이다. 이를 공개 App Store 출시와 구분해야 한다.

📈 투자·시사 포인트

• 제품 경쟁력 관점에서는 코드 생성 이후의 서명 빌드, 스토어 자료 생성, 정책 점검을 얼마나 연결하는지가 평가 항목이 된다.
• 개발 도구 도입 시에는 첫 결과물 생성 시간과 함께 제출 준비 시간, 수정 반복 횟수, 실제 설치 성공 여부를 비교할 수 있다.
• 발표자가 강조한 배포 지원의 가치는 실제 승인 사례와 감사 정확도로 검증필요가 있다. 한 번의 시연만으로 경쟁 우위를 확정하기는 어렵다.
• 영상에는 할인 코드와 구매 유도가 포함된다. 제품 선택이나 사업성 판단에는 시연에서 확인된 기능과 발표자의 홍보성 평가를 구분해 반영해야 한다.

⚠️ 불확실하거나 확인이 필요한 부분

• 공개 App Store 또는 Google Play에서 심사를 통과하고 출시됐다는 결과는 나오지 않는다. TestFlight 설치는 확인되지만 제목이 암시하는 최종 출시까지 입증된 것은 아니다.
• 제출 전 감사에서 발견된 구체적인 문제와 수정 후 재검사 결과는 설명되지 않는다. 발표자는 수정이 완료됐다고 말하지만 감사의 탐지 범위와 정확도는 확인하기 어렵다.
• 모든 AI 빌더가 빠르게 코드를 만든다는 주장, 개발팀의 경력·기업공개 이력, 기존 방식 대비 작업 기간은 발표자의 설명이다. 영상 안에 비교 실험이나 별도 검증 자료는 없다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 만들 앱의 화면, 데이터 기록 방식, 조건부 규칙을 구체적인 자연어 요구사항으로 작성한다.
• 운동 앱 사례처럼 조건 충족·미충족 상황과 기본값을 나눠 확인하고, 잘못된 동작을 피드백해 수정한다.
• 플랫폼별 빌드를 생성한 뒤 작은 휴대전화와 태블릿 등 여러 화면에서 잘림과 이미지 비율을 점검한다.
• 생성된 스토어 소개문·스크린샷이 실제 기능과 일치하는지 확인하고, 개인정보처리방침·데이터 안전성 선언·연령 등급을 검토한다.

❓ 열린 질문

• 이번 앱은 최종적으로 App Store와 Google Play의 공개 출시 심사를 통과했는가?
• 제출 전 감사가 어떤 정책 문제를 탐지하며, 놓치는 문제와 잘못 경고하는 문제는 얼마나 있는가?
• Android에서도 실제 기기 설치와 Google Play 제출까지 같은 흐름으로 완료할 수 있는가?