Swift, Apple conventions and the road through review
SwiftUI or UIKit
SwiftUI is where Apple is putting its effort, and it is faster to build with: less code, live previews and state that drives the screen directly. We use it for new apps by default. UIKit is still the better tool for some jobs, including complex collection layouts, heavily customized text editing and apps that must support older iOS versions where SwiftUI is less complete. The two mix well, so the choice is made screen by screen. Underneath, we use Swift concurrency with async and await for networking, and SwiftData or Core Data when the app stores records on the device.
Designing for the platform
Apple publishes its Human Interface Guidelines, and reviewers and users both hold apps to them. In practice that means standard navigation and back-swipe, system sheets and menus, text that scales with the Dynamic Type setting, proper safe-area handling and support for dark mode. It also means asking for permissions in context. A camera prompt that appears when someone taps "Scan" makes sense to the user in a way that a prompt at first launch does not.
What App Review looks for
Rejections are mostly predictable. Reviewers need a working demo login and notes that explain anything unusual. Apps that let people create an account must let them delete it from inside the app. If you offer third-party sign-in, expect to add Sign in with Apple or an equivalent privacy-focused option. Each permission needs a purpose string that says what the data is for. We keep a checklist of the guidelines that apply to your app and go through it at scoping, again before the first TestFlight build and again before submission.
In-app purchase, explained plainly
Digital goods and services used inside the app (subscriptions, premium features, course access, credits) generally have to be sold through Apple's in-app purchase system, and Apple keeps a commission. Physical goods and real-world services such as rides, food or appointments use ordinary payment gateways and Apple Pay. The rules on linking out to web payments differ by country and have changed more than once, so we check the current guidelines for your storefronts and do not rely on what was true last year. On the technical side we implement StoreKit in the app and validate transactions on your server, which also receives Apple's server notifications for renewals, refunds and cancellations.
TestFlight, APNs and privacy labels
Internal testers get TestFlight builds shortly after upload. External testers need a short beta review first, so we invite them early. Push notifications run through the Apple Push Notification service using a token-based key, with separate sandbox and production environments that your backend must address correctly. Before release, App Store Connect asks what data the app and its third-party SDKs collect. Those privacy labels are public, and we fill them in from an audit of the code and its SDKs, not from memory. For the server side of push and purchases, see connecting the app to its backend.