iOS Apps Built the Way Apple Expects Them to Be Built

SwiftUI for most new work, UIKit where you need control it does not yet give you. SwiftUI is substantially faster to build in and its accessibility and dark mode support are better by default. UIKit still wins for highly customised collection layouts, complex camera interfaces and precise scroll behaviour. Mixing them in one app is normal and supported, so this is not an all-or-nothing decision.

Usually 24 to 48 hours for a straightforward submission, though it can extend to a week or more for a first submission in a scrutinised category. Health, finance, dating and anything involving children's data get closer review. We prepare submissions against current guidelines to avoid the common rejection causes, and we plan a one-to-two week buffer before any hard launch date.

Yes, and it should be under your organisation, not ours. An Apple Developer Program membership costs 99 US dollars a year and requires a D-U-N-S number for organisation accounts, which can take a week or two to obtain, so we start that early. We can be added as team members to build and submit, and you retain ownership of the app listing, which matters if you ever change development partner.

Yes, and incrementally rather than all at once. Swift and Objective-C interoperate, so the practical approach is to add new features in Swift and convert existing modules when they need changes anyway, prioritising the code that changes most often. A full rewrite is occasionally justified when the app is small or the architecture is the actual problem, but for a large app incremental migration carries far less risk.

Yes. Watch apps make sense when there is a genuine wrist-first use case such as tracking or quick confirmation, and we will say when there is not. iPad support is worth doing properly rather than shipping a stretched phone layout: split view, multitasking and pointer support are what make an iPad app feel native. We scope both explicitly rather than assuming them.