What Swift is
Apple's language for everything they make: iPhone, iPad, Mac, Watch and TV. It's fast, strongly typed, and unusually careful about the mistakes that cause crashes — a value that might be missing has to be handled explicitly.
technologies / swift
Swift for apps that should feel like the platform.
Native iPhone and Mac applications, including one of our own, where platform integration and polish are the point rather than a nice-to-have.
why swift
What native buys you.
On Apple platforms, native still wins on the things users can feel but can't name.
Feel
Right on the platform
Gestures, animations and system behaviour match what the user already expects, with nothing to reimplement.
Access
Everything the OS offers
Widgets, shortcuts, menu bar, file system and background work, available the day Apple ships them.
Performance
Fast and frugal
Compiled native code, which shows in launch time and battery use on older devices.
Distribution
Signed and notarised
Store submission or direct download, both signed and notarised properly. We do this for our own Mac app.
01
What we build with Swift
Mac applications
We build Mac software, including an app of our own that works entirely on the device. Mac software is a small field and we're in it.
iPhone apps that need the platform properly
Widgets, background processing, Apple Pay, App Clips, on-device machine learning. Things a cross-platform layer either can't reach or reaches badly.
On-device processing
Work that must not leave the machine for privacy or latency reasons. Apple's chips are very good at this and Swift is how you get at them.
Native modules for a React Native app
When a cross-platform app needs one thing done properly on iOS, it's written in Swift and bridged.
App Store submission and review
Getting an app through review, with the privacy declarations and entitlements right the first time.
the essentials
What Swift actually is.
Written for someone deciding, not for someone who already knows. Skip it if you do.
When native is worth the extra cost
When the app IS the product rather than a window onto a web service. If it must be excellent on iPhone, use the newest platform features the week they ship, or run heavy work on the device, native pays for itself. If it's a form and a list over an API, it usually doesn't.
What you're buying with it
Access and longevity. Everything Apple ships is available on day one instead of when a bridging library catches up, and Swift code ages well because Apple maintains the platform underneath it.
The cost, stated plainly
It only runs on Apple's platforms. An Android version is a second application with a second team, and that's the whole trade-off. We would rather set that out at the start than discover it at the halfway point.
Store
Your app was built against an old SDK
Apple raises the minimum periodically and refuses submissions below it. This becomes urgent without warning.
Language
The codebase is Objective-C
It still works, but the pool of people who want to maintain it's shrinking. Swift and Objective-C coexist, so the move can be gradual.
Ownership
You don't control the developer account
More common than it should be, and it's the one problem that can stop you shipping entirely. Worth resolving before anything technical.
questions
Straight answers.
Swift or React Native?
Swift when the app is Apple-only, or when platform integration and feel are the product. React Native when you need Android too and the app is mostly screens and data.
Do you build for Mac as well as iPhone?
Yes. We build and ship a Mac application of our own, so the desktop side including signing, notarisation and distribution is familiar ground.
Can you take over an existing Swift app?
Yes. Expired certificates and outdated dependencies are the usual blockers on an inherited app, and both are recoverable.
Swift or React Native?
Swift when the app is the product, needs the newest platform features, or does heavy on-device work. React Native when you need both platforms and the app is mostly screens over an API. We'll say which yours is.
Can you take over an existing iOS app?
Yes. The first job is always getting a clean machine to build and sign it, which is where most inherited apps are actually stuck.
Tell us what you want to build or improve.
A few lines are enough to start. You get a reply within two working days.