Build With Me / Apple / iOS

Build your iOS app with me.

From an idea on paper to an application people can actually use.

A native iPhone app is built in Swift and SwiftUI, in Xcode on a Mac, then tested with TestFlight and published through App Store Connect after Apple’s review. Before writing code, check that the problem is real and that native is needed: a phone-friendly web app is often enough for a first version. This page gives the whole path, in twenty stages, with the rules that get apps rejected.

Checked on

In brief

Language and UI
Swift and SwiftUI; the examples here target iOS 17 (@Observable, SwiftData)
Tool
Xcode, Mac only; uploads need Xcode 26 or later since 28 April 2026
Account
Apple Developer Program: 99 USD per membership year (or local currency) for TestFlight and the App Store
Beta
TestFlight: 100 internal testers, 10,000 external, builds testable for 90 days
Review
Per Apple: 50% of submissions reviewed in under 24 hours, 90% in under 48 hours — the decision remains Apple’s

Three ways to build

Learn, build it together, or have it built.

01 · Learn and buildResources available — A guide on this site and the official documentation.

Learn iOS development

The twenty-stage path below, each stage linked to an official Apple resource, and the project builder for your roadmap. Build School teaches how to build web products, not Swift: for iOS, it is these guides and Apple’s tutorials.

02 · Build it togetherOn request — Reviewed case by case, with no price or date promised.

Build your iOS app together

You build; Bynilson reviews your scope, architecture and milestones, in writing. Reviewed case by case: there is no native app published in the Bynilson portfolio yet, and the answer may be a referral to an iOS specialist.

03 · Have it builtNot offered — Bynilson does not do this; here is what helps instead.

Have your iOS app developed

Bynilson does not deliver native mobile apps. What helps instead: the project builder produces a roadmap and a brief to hand to a specialist iOS studio, and the “hire or outsource” guide helps you decide how to staff it.

Bynilson does not deliver native mobile apps: the builder gives you the roadmap and the brief to hand to a specialist studio. A request for guidance (you build, with an outside review) is reviewed case by case.

01 — Why iOS

When a native iPhone app is the right call

  • The product lives in the pocket: opened several times a day, for a few seconds each time.
  • It depends on the phone: camera, location, health data, notifications, widgets, Shortcuts.
  • It must work without a network, or better than a website when the network is poor.
  • Your users look for this kind of tool in the App Store, and paying there feels natural to them.

02 — Native or cross-platform

Native SwiftUI, React Native, Flutter, or the web?

No approach wins everywhere. The right choice depends on the devices you target, the system features you need and the team that will maintain the code.

Four ways to build a mobile app
ApproachLanguageStrengthsLimitsFits when
Native: SwiftUI (iOS), Kotlin and Jetpack Compose (Android)Swift; KotlinFull, immediate access to each system’s APIs, interface true to platform conventions, performanceTwo codebases if you also want AndroidiPhone first, or deep system features (health, widgets, camera)
React Native, often with ExpoJavaScript / TypeScriptOne codebase for iOS and Android, native interface components; Expo offers a hosted service that builds the appsRecent or rare APIs go through native modules; one more layer to keep up to dateiOS and Android together, a team already fluent in TypeScript
FlutterDartOne codebase for iOS, Android, web and desktop; identical rendering everywhereInterface drawn by Flutter, not by the system: Apple conventions must be reproducedThe same branded interface on every platform
Phone-friendly web app (PWA)HTML, CSS, JavaScriptNo store, no review, one version, installable on the home screenNarrower access to phone features, no App Store presenceValidating an idea, a tool made mostly of forms and content

What about Android? Native Android is written in Kotlin with Jetpack Compose and published through Google’s Play Console; Google’s official courses start from zero. As with iOS, Bynilson does not deliver Android apps: the project builder produces the roadmap and the brief.

03 — Kinds of app

What changes with the kind of app

The kind of app decides the frameworks, the App Store rules that apply and the rejection risks.

Utility

One precise task, done fast: a converter, a timer, a scanner.

The approachSwiftUI, local storage with SwiftData, often no server. A widget and App Intents actions (Shortcuts, Siri) add a lot for little code.

The trapRule 4.2 rejects apps that are too thin: an app must be useful beyond a web page or a trivial function.

Productivity

Lists, notes, trackers, documents — used every day.

The approachSwiftData locally; iCloud sync if all your users are on Apple, otherwise your own server.

The trapA subscription must be available across all of the person’s devices (3.1.2(a)); iPhone apps should also run on iPad (2.4.1).

Social

Profiles, feeds, messages, content posted by users.

The approachA server and a database are essential, with notifications sent from the server.

The trapRule 1.2 requires filtering of objectionable content, reporting with timely responses, blocking of abusive users and published contact information. Moderation is ongoing work, not a feature.

Education

Lessons, exercises, progress.

The approachContent and progress locally or on a server; paid digital content through in-app purchase (3.1.1).

The trapAn app for children in the Kids Category follows stricter rules (links out, purchases, data).

Business

A tool for a team or for a company’s clients.

The approachOften a web app first; a native app when use is mobile and repeated. Apple provides private distribution for organisations.

The trapIf the app requires sign-in, give Apple a demo account for review (2.1).

Travel

Itineraries, bookings, maps, offline documents.

The approachCore Location for position, cached data for offline use, a server for bookings.

The trapEvery permission needs a clear purpose string (5.1.1(ii)), and background location is only allowed for its intended purpose (2.5.4).

Health and wellbeing

Tracking activity, habits, symptoms.

The approachHealthKit to read or write health data, with the person’s explicit permission.

The trapHealth data cannot be used for advertising (5.1.3); a medical app is reviewed with greater scrutiny and must support its accuracy claims (1.4.1). Nothing here stands in for regulatory approval: a medical device needs specialist advice.

Commerce

Selling products or services.

The approachPhysical goods or services consumed outside the app: Apple Pay or card payment, not in-app purchase (3.1.3(e)). Digital content and features: in-app purchase (3.1.1). A server handles orders.

The trapPayment rules differ in the United States and the EU: read the current version before designing payment.

Creative tools

Photo, video, drawing, music.

The approachAVFoundation for camera and audio, PhotoKit for the photo library, PencilKit on iPad.

The trapHeavy files and performance are tested on a real device; ask for photo access only when it is needed.

AI experiences

Summarise, generate, recognise, converse.

The approachOn device: Foundation Models (iOS 26+, devices that support Apple Intelligence) or Core ML. Otherwise a model API called from your server — never an API key inside the app.

The trapSharing personal data with a third-party AI must be disclosed clearly, with explicit permission (5.1.2(i)); an AI content-creation app also falls under rule 1.2.

04 — Technologies

The building blocks of an iPhone app

SwiftUI

The interface, described as a function of state.

When: Any new app.

Not when: A component is missing: wrap a UIKit element instead of rewriting everything.

SwiftUI documentationApple

Observation (@Observable)

State tracking that refreshes the views that read it (iOS 17+).

When: The model shared by several screens.

Not when: An app that must run before iOS 17: it needs the older ObservableObject approach.

ObservationApple

NavigationStack

Value-driven navigation, with links that do not depend on screens (iOS 16+).

When: Lists and details, multi-step flows.

NavigationStackApple

SwiftData

Local storage for your Swift models (iOS 17+), with optional iCloud sync.

When: Offline data, drafts, cache.

Not when: Data shared between users: it lives on a server.

SwiftDataApple

Authentication Services

Sign-in: Sign in with Apple, passkeys, sign-in to web services.

When: As soon as there are accounts.

Not when: An app with no account-based features: let people use it without signing in (5.1.1(v)).

Authentication ServicesApple

StoreKit

In-app purchase and subscriptions.

When: Paid digital content or features (3.1.1).

Not when: Physical goods and services consumed outside the app (3.1.3(e)).

StoreKitApple

User Notifications

Local notifications, or notifications sent from your server.

When: A reminder or expected information.

Not when: Marketing without explicit consent (4.5.4).

User NotificationsApple

WidgetKit and App Intents

Widgets, Live Activities, controls; actions for Siri, Spotlight and Shortcuts.

When: Information checked at a glance, an action people repeat.

Not when: Before the main flow works.

WidgetKitApple

Core Location, AVFoundation, PhotoKit

Location, camera and audio, the photo library.

When: When the core feature depends on them.

Not when: “Just in case”: every permission asked without a reason worries people and can get the app rejected.

Core LocationApple

Keychain

Encrypted storage for tokens and passwords.

When: Every sign-in token.

Not when: Never a secret in UserDefaults.

Keychain ServicesApple

Swift Testing

Swift’s testing framework (Xcode 16+).

When: Business rules, the model, calculations.

Swift TestingApple

05 — The path

From idea to App Store, in twenty stages

Every stage links to an official resource. Do them in order: skipping validation or scope costs more than any line of code.

  1. 01

    Validate the problem

    Talk to five people who have the problem. Write down what they do today instead of using your app, and what it costs them. No code until that is clear.

    AvailablePrototype or v1?

  2. 02

    Define the first version (MVP)

    One sentence for the outcome, three features at most, and a list of what will wait. What is not on the list does not get built.

    AvailableBuild OS — the 22 stages of a product (in French)

  3. 03

    Understand Apple’s ecosystem

    Read “Designing for iOS”: screen sizes, navigation, gestures, accessibility. An app that follows these conventions feels obvious to its users.

    AvailableDesigning for iOSApple

  4. 04

    Install and configure Xcode

    Install Xcode from the Mac App Store, create an “App” project with the SwiftUI interface, run it in the simulator, then on your iPhone with a free Apple Account.

    AvailableRunning your app on simulated or physical devicesApple

  5. 05

    Learn Swift fundamentals

    Types, optionals, structs and classes, functions, error handling. Apple’s “Develop in Swift” tutorials start from zero.

    AvailableDevelop in Swift TutorialsApple

  6. 06

    Build interfaces with SwiftUI

    Views, layout, lists, forms. Build the screens first with sample data, no server.

    AvailableSwiftUI TutorialsApple

  7. 07

    Manage app state

    One shared @Observable model, @State for a screen’s local state. One source of truth per piece of data.

    AvailableObservationApple

  8. 08

    Implement navigation

    NavigationStack for lists and details, tabs if there are several areas. Navigate by values, not by nesting screens.

    AvailableNavigationStackApple

  9. 09

    Persist data

    SwiftData for what stays on the device. Decide early what must also exist on a server.

    AvailableSwiftDataApple

  10. 10

    Integrate APIs

    Network calls with URLSession and async/await, JSON decoding with Codable, visible loading and error states. Secret keys stay on your server, never in the app.

    AvailableURLSessionApple

  11. 11

    Implement authentication

    Only if the product has account-based features. Plan in-app account deletion (5.1.1(v)) and, with Google or Facebook sign-in, an equivalent login option (4.8).

    AvailableAuthentication ServicesApple

  12. 12

    Add payments when appropriate

    In-app purchase for digital goods, another payment method for physical ones. Test purchases in StoreKit’s test environment before selling.

    AvailableStoreKitApple

  13. 13

    Handle privacy and permissions

    A purpose string for every permission, privacy details in App Store Connect, a privacy manifest if you use required-reason APIs.

    AvailableApp privacy details on the App StoreApple

  14. 14

    Test on simulators and devices

    Several screen sizes in the simulator, then a real iPhone: slow network, airplane mode, large text, VoiceOver.

    AvailableRunning your app on simulated or physical devicesApple

  15. 15

    Prepare App Store assets

    Screenshots that show the app in use (2.3.3), description, keywords, age rating, support URL and privacy policy.

    AvailableApp Store Connect HelpApple

  16. 16

    Distribute through TestFlight

    Internal testers first, then external ones. Collect feedback in TestFlight and fix before submitting.

    AvailableTestFlight overviewApple

  17. 17

    Submit through App Store Connect

    A build uploaded from Xcode 26 or later, a complete listing, review notes with a demo account if the app requires sign-in.

    AvailableDistributing your app for beta testing and releasesApple

  18. 18

    Handle review feedback

    A rejection cites a rule: fix exactly that point, reply in App Store Connect, or explain if it is a misunderstanding. The decision is Apple’s.

    AvailableApp Review GuidelinesApple

  19. 19

    Monitor crashes and user feedback

    Crash reports in Xcode’s Organizer, App Store reviews, TestFlight feedback. Fix what blocks the main flow first.

    AvailableAcquiring crash reports and diagnostic logsApple

  20. 20

    Iterate after launch

    A new iOS every year and publishing requirements that rise: plan a yearly update, and read Apple’s upcoming requirements page.

    AvailableUpcoming requirementsApple

06 — Example

A small, complete SwiftUI app

A habit list with a detail screen: an @Observable model, a NavigationStack, no dependencies. To try it, create a SwiftUI “App” project in Xcode, replace the contents of the “…App.swift” file with the second file, add the first one and delete ContentView.swift.

HabitStore.swift — the model
import Foundation
import Observation

struct Habit: Identifiable, Hashable {
    let id = UUID()
    var name: String
    var isDoneToday = false
}

// @Observable (iOS 17+): views that read a property refresh when it changes.
@Observable
final class HabitStore {
    var habits: [Habit] = [
        Habit(name: "Read 10 pages"),
        Habit(name: "Walk 20 minutes"),
    ]

    func habit(with id: Habit.ID) -> Habit? {
        habits.first { $0.id == id }
    }

    func toggle(_ id: Habit.ID) {
        guard let index = habits.firstIndex(where: { $0.id == id }) else { return }
        habits[index].isDoneToday.toggle()
    }
}

Typechecked with Xcode 27.1 (iOS SDK 27.1), target iOS 17, Swift 5 and Swift 6 language modes — 2026-10-23

HabitsApp.swift — the app and its two screens
import SwiftUI

@main
struct HabitsApp: App {
    @State private var store = HabitStore()

    var body: some Scene {
        WindowGroup {
            HabitListView(store: store)
        }
    }
}

struct HabitListView: View {
    let store: HabitStore

    var body: some View {
        // NavigationStack (iOS 16+): navigation driven by values, not by views.
        NavigationStack {
            List(store.habits) { habit in
                NavigationLink(value: habit.id) {
                    Label(habit.name, systemImage: habit.isDoneToday ? "checkmark.circle.fill" : "circle")
                }
            }
            .navigationTitle("Habits")
            .navigationDestination(for: Habit.ID.self) { id in
                HabitDetailView(store: store, id: id)
            }
        }
    }
}

struct HabitDetailView: View {
    let store: HabitStore
    let id: Habit.ID

    var body: some View {
        if let habit = store.habit(with: id) {
            VStack(spacing: 24) {
                Text(habit.name).font(.title2)
                Button(habit.isDoneToday ? "Mark as not done" : "Mark as done") {
                    store.toggle(id)
                }
                .buttonStyle(.borderedProminent)
            }
            .padding()
            .navigationTitle("Today")
        } else {
            ContentUnavailableView("Habit not found", systemImage: "questionmark.circle")
        }
    }
}

Typechecked with Xcode 27.1 (iOS SDK 27.1), target iOS 17, Swift 5 and Swift 6 language modes — 2026-10-23

07 — Planner

Scope your iOS app

Pick the kind of app and the features it needs: the planner lists the frameworks, the App Store rules that apply and what to plan for, with the reason for each line.

Planner

What kind of app?
What the app needs
For whom?

Answer a question to see what applies to your app.

08 — App Store

Ready to submit?

The points that most often get a first version rejected or delayed, according to Apple’s rules.

App Store submission checklist

09 — TestFlight

Get it tested before you publish

Internal testers
Up to 100 members of your App Store Connect team, with no prior review.
External testers
Up to 10,000 people, by email or public link. The first build sent to external testers may need Apple’s review.
Duration
Each build can be tested for 90 days.
Review timing
Apple says it reviews at least 50% of submissions in under 24 hours and 90% in under 48 hours.

10 — After launch

A published app is a product to keep alive

  • Read crash reports every week at first, then at every release.
  • Answer reviews and sort feedback: bug, confusion, feature request.
  • Measure the main flow without collecting more than you need — and declare it in the privacy details.
  • Rebuild and retest at every major iOS release; follow Apple’s upcoming requirements page.

Frequently asked questions

  • How much does iOS app development cost?

    It depends on the number of screens, any server, accounts, payments and system features. Bynilson does not publish a price for native apps and does not make one up. The known fixed cost: the Apple Developer Program, 99 USD per membership year (or local currency). The project builder produces a brief that iOS studios can quote.

  • Can I build an iPhone app without coding?

    Some no-code tools produce mobile apps; check what they generate (a wrapped web page risks rejection under rule 4.2) and that you can get your data out. To learn, Apple’s “Develop in Swift” tutorials start from zero.

  • SwiftUI or React Native?

    SwiftUI if the iPhone is the main target or the app depends on system features. React Native (often with Expo) if you target iOS and Android together with a team fluent in TypeScript. Flutter if you want the same interface everywhere. The table above details the trade-offs.

  • How do I publish an app on the App Store?

    Join the Apple Developer Program, create the listing in App Store Connect, upload a build from Xcode 26 or later, complete the privacy details and screenshots, test with TestFlight, then submit for review. The checklist on this page covers what gets a first version rejected.

  • What is TestFlight for?

    Testing a version before publishing it: up to 100 internal and 10,000 external testers, each build testable for 90 days. The first build sent to external testers may need Apple’s review.

  • Do I need a Mac?

    For a native app, yes: Xcode runs only on a Mac. With React Native and Expo, a hosted service can build the iOS app, but you still need an Apple Developer account to publish.

  • Can Bynilson develop my iOS app?

    No, Bynilson does not deliver native mobile apps. You can build it yourself with written guidance, reviewed case by case (describe your project), or hand the builder’s brief to an iOS studio — the hire or outsource guide helps you choose.

  • Will my app be approved?

    Nobody but Apple can say. The checklist reduces avoidable rejections; a rejection cites a specific rule, which you fix before resubmitting.

Sources

Ready for the next step?

Describe your project in a few answers: you get an explained plan and a roadmap, with no account and no commitment.

danilson.daveigaramos.pro@gmail.com