Cheffusion Technologies
Mobile

iOS Applications

Native iPhone and iPad work that survives the annual OS release

How this is usually engaged

A first release is usually ten to sixteen weeks, followed by a maintenance agreement that explicitly covers the September OS release each year. You will need an Apple Developer Program account in your organisation's name — we work inside yours rather than publishing under ours, so the app is always yours to move.

Start a project brief
Practice
Mobile Engineering
Sectors
4 served
Process
5 stages
Standard
Built and tested to WCAG 2.2 AA

Swift applications for iPhone and iPad, taken through App Review and maintained across Apple's yearly release cycle rather than abandoned at launch.

01What this solves

The problem this addresses

Most iOS projects go wrong after the first submission, not before it. The app is built against one iOS version, App Review returns it for a privacy declaration nobody prepared, and a year later a new OS breaks a screen that nobody is funded to fix. Meanwhile the app is downloaded once, used twice and deleted, because it does nothing the website could not do.

02Capabilities

What is included

01

Native interface in Swift

SwiftUI for the bulk of the application, with UIKit where a list, a camera surface or a custom transition needs it. Platform conventions are followed, so the app behaves the way an iPhone owner expects without being taught.

02

Offline-first data and sync

The device database is treated as the source of truth for reading, with a queue for changes made while offline and a defined resolution for conflicts. We agree what happens to a record edited in two places before we build it, not after a user reports it.

03

Device capability integration

Camera and document scanning, location and geofencing, Bluetooth peripherals, biometric authentication, background refresh and push notifications — each with the permission prompt asked for at the moment it makes sense, not on first launch.

04

App Store submission and release management

Privacy nutrition labels, export compliance answers, store listing, screenshots per device size, phased rollout and TestFlight distribution to your internal testers before anything reaches the public.

05

Accessibility on iOS

VoiceOver labels and rotor order, Dynamic Type that survives the largest setting, adequate contrast, reduced-motion support and touch targets that work for someone on a train. Tested on a device with VoiceOver switched on, not only with a scanner.

06

Performance and battery profiling

Launch time, scroll performance, memory and energy measured in Instruments on an older device we keep for the purpose, because the newest phone hides almost every problem worth finding.

03Use cases

Where this work usually starts

01

Equipping a field team

Engineers, drivers or inspectors capturing jobs, photographs and signatures in places with no signal, then syncing when they are back in range.

Logistics & Transport

02

A customer app that earns its icon

Where saved payment details, a scannable pass, push notifications and offline access give people a reason to keep the app rather than reopen the website.

Retail

03

Replacing a wrapped website

An existing app that is a browser view in a shell, scoring badly in reviews for slowness and for not behaving like an iPhone app. The rebuild is usually narrower in scope than the original.

04Approach

How we approach it

We decide first whether an app is warranted at all — an app earns its place when it needs the camera, location, offline use, background work or notifications, and rarely otherwise. From there we build in Swift with SwiftUI, dropping to UIKit where a screen genuinely needs it, treat the local database as the source of truth so the interface stays usable without a connection, and prepare the App Store listing, privacy declarations and TestFlight builds as part of the work rather than in the last week.

05Process

How the work runs

The order matters more than the ceremony. Stages overlap in practice, but none of them is skipped.

  1. 01

    Platform decision

    Whether this needs an app, needs iOS first, or is better served by the web. Written down with the reasoning, so it can be revisited.

  2. 02

    Flows and offline model

    The tasks people perform standing up, and what each of them must still do with no connection.

  3. 03

    Interface design on device

    Screens reviewed on real hardware at real type sizes, including the largest Dynamic Type setting.

  4. 04

    Build and TestFlight

    Fortnightly builds to your testers from early on, so feedback arrives while it is still cheap to act on.

  5. 05

    Submission and phased release

    Review submitted with time to spare, then a staged rollout with crash reporting watched closely.

06Deliverables

What you receive

Everything below is handed over as part of the engagement. If you take the work elsewhere afterwards, the next team has what it needs.

  • iOS application source and signing configurationIn your repository, with certificates and profiles held in your Apple account.
  • TestFlight builds and release notes
  • App Store listing assets and privacy declarations
  • Offline and sync specificationWhat is cached, for how long, and how conflicting edits resolve.
  • Accessibility and performance test results
  • Build pipeline and release runbook
07Technologies

What we use on this work

These entries are drawn from our managed technology directory, which records why each one is in our stack and what we reach for it for. Nothing outside this list is claimed for this service.

Languages & Runtimes

  • Node.js

Mobile

  • Swift

Data & Storage

  • PostgreSQL

Cloud Platforms

  • Amazon Web Services

DevOps & Operations

  • GitHub Actions
  • Sentry
The full technology directory

Highlighted entries are used routinely on delivery work

08Security

How this is kept secure

Credentials and tokens live in the Keychain, never in user defaults or the app bundle, and a Face ID or Touch ID check gates access to anything sensitive held on the device. API keys stay on your server; the app talks to your backend, not to third-party services directly. Transport is TLS with App Transport Security left switched on, and locally cached records are limited to what the screen actually needs and cleared on sign-out.

Our full security and quality approach
09Questions

Asked before we start

Do we actually need an iOS app?

Often not, and we would rather say so at the start. If your users are online whenever they use the product and you need nothing from the hardware, a fast responsive site avoids the app stores, the review queues and the yearly maintenance entirely. An app becomes the right answer when offline use, hardware access, background work or notifications are central to the task.

What happens when Apple releases a new iOS version?

Beta versions appear in the summer and the public release lands in the autumn. Our maintenance agreements include testing against the beta and shipping any fix before the public release, because a broken app is far more visible than a late one. Without a maintenance agreement, this is work you would need to commission each year.

Who owns the App Store listing?

You do. We work inside your organisation's Apple Developer Program account and configure signing so that your team, or a future supplier, can build and submit without us. Publishing client apps under an agency account is common and it makes leaving that agency painful.

Can you guarantee approval by App Review?

No, and nobody can. We can reduce the risk considerably by reading the current guidelines against your feature list before we build, preparing privacy declarations honestly, and avoiding the categories that attract scrutiny. Where a rejection does arrive, responding to it is included in the engagement.

START HERE

Talk to us about iOS Applications

The project brief takes about five minutes and gives us enough to have a useful first conversation about iOS Applications rather than a generic one. If you would rather just ask a question, the short form is there for that.

Start a projectSend a short message

We read every enquiry ourselves. If we are not the right fit, we will say so and tell you what to look for instead.