Utility
One precise task, done fast: a converter, a timer, a scanner.
Build With Me / Apple / iOS
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
Three ways to build
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.
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.
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
02 — Native or cross-platform
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.
| Approach | Language | Strengths | Limits | Fits when |
|---|---|---|---|---|
| Native: SwiftUI (iOS), Kotlin and Jetpack Compose (Android) | Swift; Kotlin | Full, immediate access to each system’s APIs, interface true to platform conventions, performance | Two codebases if you also want Android | iPhone first, or deep system features (health, widgets, camera) |
| React Native, often with Expo | JavaScript / TypeScript | One codebase for iOS and Android, native interface components; Expo offers a hosted service that builds the apps | Recent or rare APIs go through native modules; one more layer to keep up to date | iOS and Android together, a team already fluent in TypeScript |
| Flutter | Dart | One codebase for iOS, Android, web and desktop; identical rendering everywhere | Interface drawn by Flutter, not by the system: Apple conventions must be reproduced | The same branded interface on every platform |
| Phone-friendly web app (PWA) | HTML, CSS, JavaScript | No store, no review, one version, installable on the home screen | Narrower access to phone features, no App Store presence | Validating 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
The kind of app decides the frameworks, the App Store rules that apply and the rejection risks.
One precise task, done fast: a converter, a timer, a scanner.
Lists, notes, trackers, documents — used every day.
Profiles, feeds, messages, content posted by users.
Lessons, exercises, progress.
A tool for a team or for a company’s clients.
Itineraries, bookings, maps, offline documents.
Tracking activity, habits, symptoms.
Selling products or services.
Photo, video, drawing, music.
Summarise, generate, recognise, converse.
04 — Technologies
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.
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.
NavigationStack
Value-driven navigation, with links that do not depend on screens (iOS 16+).
When: Lists and details, multi-step flows.
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.
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)).
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)).
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).
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.
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.
Keychain
Encrypted storage for tokens and passwords.
Swift Testing
Swift’s testing framework (Xcode 16+).
When: Business rules, the model, calculations.
05 — The path
Every stage links to an official resource. Do them in order: skipping validation or scope costs more than any line of code.
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?
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.
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
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
Learn Swift fundamentals
Types, optionals, structs and classes, functions, error handling. Apple’s “Develop in Swift” tutorials start from zero.
AvailableDevelop in Swift TutorialsApple
Build interfaces with SwiftUI
Views, layout, lists, forms. Build the screens first with sample data, no server.
AvailableSwiftUI TutorialsApple
Manage app state
One shared @Observable model, @State for a screen’s local state. One source of truth per piece of data.
AvailableObservationApple
Implement navigation
NavigationStack for lists and details, tabs if there are several areas. Navigate by values, not by nesting screens.
AvailableNavigationStackApple
Persist data
SwiftData for what stays on the device. Decide early what must also exist on a server.
AvailableSwiftDataApple
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
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
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
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.
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
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
Distribute through TestFlight
Internal testers first, then external ones. Collect feedback in TestFlight and fix before submitting.
AvailableTestFlight overviewApple
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
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
Monitor crashes and user feedback
Crash reports in Xcode’s Organizer, App Store reviews, TestFlight feedback. Fix what blocks the main flow first.
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 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.
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
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
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.
Answer a question to see what applies to your app.
08 — App Store
The points that most often get a first version rejected or delayed, according to Apple’s rules.
App Store submission checklist
09 — TestFlight
10 — After launch
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.
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 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.
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.
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.
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.
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.
Nobody but Apple can say. The checklist reduces avoidable rejections; a rejection cites a specific rule, which you fix before resubmitting.