Native iOS
application development
in Long Beach

Every new iOS project asks the same question early. Should the interface be written in SwiftUI or in UIKit? The honest answer for most apps is SwiftUI with pockets of UIKit. The details depend on the minimum iOS version, the kind of screens and the people who will maintain the code.

SwiftUI describes the interface as a function of state. Change the data and the view updates. Previews in Xcode show changes quickly, and common screens need far less code than before. Lists, forms, settings, onboarding and detail pages are comfortable territory. For a typical business app, most screens now fall into that group.

The minimum supported iOS version shapes the choice more than taste does. SwiftUI gains important features with each yearly release. Navigation with NavigationStack, the Observable macro for state and many layout tools arrived in specific versions. An app that must support older systems loses access to them and ends up writing workarounds. Check which APIs the design needs, then compare that list with the version window.

UIKit remains stronger in some areas. Very large, complex collection views with custom layouts and precise scrolling behaviour. Rich text editing. Camera and media interfaces with fine control. Screens where a designer expects pixel-exact transitions. UIKit has had many years to mature, and its behaviour under pressure is well documented.

The two frameworks mix well. UIHostingController puts a SwiftUI view inside a UIKit screen. UIViewRepresentable and UIViewControllerRepresentable do the reverse. A SwiftUI app can use a UIKit component for one difficult screen. An older UIKit app can add new features in SwiftUI without a rewrite.

State management is where SwiftUI projects succeed or struggle. Decide early how data flows. Which objects own the state, how screens receive dependencies, where network calls live. Without a clear rule, views start to fetch data on their own and redraw more than expected. Performance problems in SwiftUI usually trace back to state that is too broad.

Testing differs as well. UIKit code often keeps logic in view controllers, which are hard to test. SwiftUI pushes teams toward separate models, which are easy to test. Snapshot tests work for both.

Accessibility support is similar in both frameworks. SwiftUI adds labels and Dynamic Type scaling with little code. UIKit needs a bit more wiring. Neither excuses a team from testing with VoiceOver on a real device.

The team matters. A group of engineers with years of UIKit experience will move faster in UIKit at first. New hires increasingly learn SwiftUI first. Over the life of an app, which can be many years, the ability to hire and onboard people counts for a lot.

A practical rule for a new app: default to SwiftUI for screens and navigation. Allow UIKit for a component when a spike of a day or two shows SwiftUI cannot meet the requirement. Record each exception with a short reason. When a later iOS release closes the gap, the list shows which parts to revisit.

Third-party libraries shift the balance too. Some popular components still exist only as UIKit views, such as certain chart, map or video players. Check the key dependencies before the first sprint. A wrapper around one UIKit view is fine. Ten wrappers suggest the screen belongs in UIKit.

Architecture choices outlast framework choices. Keep business logic, networking and storage outside the view layer. Then the interface can move between frameworks screen by screen without rewriting the rest of the app.

An app translated late usually looks translated. Buttons cut off words, dates appear in the wrong order and plurals read like a machine wrote them. Most of that pain comes from code written without localization in mind. The fix costs little at the start and a lot at the end.

Xcode now uses String Catalogs, files with the xcstrings extension. The build collects every localizable string from the code into one catalog automatically. Translators see each key with a comment, a state for each language and a flag for stale entries. It replaces the older strings and stringsdict files, and it can import them.

Write every user-facing string through the localization system from the first screen. In SwiftUI, a Text view with a literal is localizable by default. In other code, use String(localized:) with a comment that explains the context. Save is ambiguous. Save as in store a file and save as in discount need different words in many languages.

Never build sentences by joining pieces. The phrase you have plus a number plus new messages works in English and breaks elsewhere, because word order changes. Use a single format string with placeholders, so translators can move the number where their grammar needs it.

Plurals need their own rules. English has two forms, one and other. Some languages have three, four or six. String Catalogs support plural variations per language, so a translator can supply every form. Device variations exist too, for text that should differ on iPhone, iPad or Mac.

Numbers, dates, currencies and measurements should never be formatted by hand. Use the formatted methods and FormatStyle types. They respect the region of the user, including decimal separators, calendar systems and the order of day and month. A price shown as a raw number with a dollar sign in front will be wrong for half the world.

Right-to-left languages such as Arabic and Hebrew mirror the layout. Auto Layout constraints with leading and trailing, and SwiftUI stacks, handle this automatically. Hard-coded left and right values do not. Directional icons, like a back arrow, must flip. SF Symbols do that for most arrows. Custom icons need a mirrored variant.

Text length changes. German and Finnish often run longer than English, while Chinese and Japanese can be shorter but taller. Design components that grow. Test with the pseudolanguages available in the scheme settings of Xcode: double length, accented characters and right to left. They reveal clipped labels in minutes, without waiting for real translations.

Remember text that does not live in the app. Push notifications, emails, error messages from the server and App Store metadata all need the same languages. Users can also pick a language per app in the Settings of the phone. The backend should respect the language the app sends, not the one it guesses.

Treat translation as part of each release. New strings appear in the catalog marked as needing work, and nothing should ship with them still untranslated.

Budget time for review by native speakers. A translation agency sees strings out of context. Screenshots of each screen help them far more than a spreadsheet. Xcode can export a localization catalog with those screenshots attached.

Installing an app is a real barrier. People who want to pay for parking, rent a scooter or order at a table rarely want a full download for one task. App Clips exist for that moment. An App Clip is a small part of an iOS app that opens instantly, does one job and leaves no icon behind.

The size limit shapes everything. An App Clip has to stay small enough to download in seconds, so it cannot carry the whole app. Recent iOS versions raised the limit for clips opened from certain sources, but the lower figure is still the safe target. Heavy frameworks, large images and unused code all count against it.

Invocation is the second design question. A clip can open from an NFC tag, a QR code, an App Clip Code, a link in Messages, a Safari banner or a place card in Maps. Each source suits a different situation. A tag on a charging point works for a physical place. A link works for an online order.

The clip should finish its task without an account. Sign in with Apple and Apple Pay make that possible: the user identifies and pays in a couple of taps. Asking for a new password inside a clip defeats its purpose.

Scope has to be tight. One task, from start to end, with the smallest set of screens. A clip that tries to show the whole catalogue or the settings becomes a slow, cut-down copy of the app. Decide which single action brings the most value to someone who has never heard of the product.

Clips have limits on what they may do. Some frameworks are unavailable, background activity is restricted and notification permission is temporary. Data stored by the clip can move to the full app if the user installs it later, which keeps the history of an order in one place.

The full app remains the destination. At the right moment the clip can suggest installing it, for example after the first successful payment. The offer should follow a good experience, not interrupt the task.

Building a clip changes the structure of the codebase. The shared features have to live in modules that both targets can use. Teams that plan for this early find it easy. Teams that add a clip to a tightly coupled app often spend more time untangling code than building the clip.

Measure clip launches and conversions to the full app separately. A clip that people use often but never install from may still be doing its job well.