Expertise · Mobile applications
We build native iOS apps in Swift, with sensors and HealthKit, and single-code applications for iOS, Android and web when the project does not require sensors. The logic core is tested separately from the screen.
Already builtThere are three in-house implementations, not one. One repository with five application targets (four iOS and one macOS) defined in `project.yml`, whose logic tests I ran today: 160 out of 160 pass. A second iOS app, in another project, with 40 Swift files and HealthKit. And a third direction, with a single codebase for iOS, Android and web, whose web version responds today. The reserve that changes the answer to the question every buyer asks first: none of our apps is published in the App Store or Google Play. There is only one reason, and it has a name — `DEVELOPMENT_TEAM` is empty in the project configuration, meaning the team identifier from the Apple Developer Program is missing. The machine has a valid signing identity, sufficient for installation on our own device, insufficient for distribution in the store. It is an account problem, not a code problem, but it remains a problem and we write it here, not in the footnote.
A mobile application has two parts that break differently. The part that reads sensors and calculates something — an angle, a score, a state — and the part that draws screens. We keep them separate, and not for aesthetic reasons: in our main iOS repository, the core files do not import the interface, so they can be compiled directly with `swiftc` on Mac and run as a regular programme, without a simulator and without a phone. The suite has 160 checks grouped into 16 stages; we ran it today and it passes in full. That is why we can say exactly what an algorithm does, instead of saying that it “works well”.
On iOS we work in Swift 6, with a minimum target of iOS 17. The same repository defines five applications as separate targets: four for iPhone and one for macOS, and the macOS one reuses fifteen files from the iOS core, without copying. Sensors are read at source: Apple’s interface for headphone sensors exposes head orientation, and the app compares the current angle with a position the user calibrates at the start of the session. The thresholds are not “internal adjustments”: below 7° it is straight, between 7° and 13° it is tilt, above 13° held for three seconds it triggers the alert, and smoothing uses an exponential average with coefficient 0.15. All four values are in four consecutive lines of code and can be shown.
When the project does not need sensors, we do not recommend native. The third direction in the portfolio is a single codebase that compiles for iPhone, Android and browser — React Native with Expo — and the web version is published and responds today. The practical difference for the client: a questionnaire, a calculator or a dashboard does not justify two teams and two repositories; an application that listens to a sensor at twenty samples per second does.
What we cannot yet do. None of our applications is in the App Store or Google Play. Not because they do not compile — they do compile, install on the simulator and pass the tests — but because in the project configuration the Apple team identifier is empty, meaning there is no Apple Developer Program enrolment linked to these builds. On Mac there is a valid signing identity, of development type, which is enough for installation on one's own device and not enough for the store. For a client project, the developer account is opened under the client company and remains theirs — that is the discussion that must be had at the beginning, not at the end.
What it covers
On iOS we use Apple interfaces directly: `CMHeadphoneMotionManager` for head orientation from the headphones, with a delegate for connect and disconnect, and explicit verification of the authorisation state before starting the stream. If the sensor is not available, the state moves to `waiting`, not to a silent error.
The analysis, calibration, history and policies files are plain Swift. They compile with `swiftc` together with the test file and run as a command-line binary. Today's result: 160 checks, 16 stages of 10, all passed. A test that runs in two seconds on Mac runs on every change; one that requires a simulator does not.
SwiftUI for both. The macOS target from the same repository includes fifteen files from the iOS core as shared sources, not as copied files, so a fix in the algorithm reaches both applications at the same time.
Expo on top of React Native, with `react-native-web` for the browser version, fonts loaded from the package and separate app icons for Android, including the monochrome variant required by the system. The same application runs on the phone and in the page, from a single repository.
We do not ‘read HealthKit’, but a table in code: eleven data types (postural angles, raw headset motion, heart rate and variability, sleep, walking, audio exposure, guided sessions and others) and five possible regimes (local only, HealthKit read, workout write, relaxation session write, route write). Each type is explicitly assigned one of the regimes. The second iOS app in the portfolio, from a private project, uses the same approach across 40 Swift files.
Four targets have `PrivacyInfo.xcprivacy` included as a build resource, not added in haste after the first rejection. The usage descriptions for motion, camera, microphone, HealthKit and notifications are written in Romanian, in the project configuration, not generated automatically.
Searching for `URLSession` in the iOS target sources returns zero results. History is stored on the device, through `FileManager` and `UserDefaults`, with an option to delete the file. The only network code in the repository is in a macOS app function, in a separate file. When an app does not need a server, we do not give it one.
The onboarding has 24 steps with unique, ordered identifiers, and some steps require explicit confirmation (sensor limits, foreground operation, privacy, readiness) without which the continue button remains blocked. State is encoded and restored. Ten of the 160 tests check exactly that.
We check which developer account exists, under which company, who administers it and what is missing for the build to be signed for the store. It is a short and boring list, but it is the difference between an app that works on our phone and one that reaches users.
What it looks like
The question is not one of taste, but of hardware: does the app need motion, health, Bluetooth, a real-time camera, background? If yes, native. If it is about forms, calculations, lists and a dashboard, a single codebase for iOS, Android and web does the same job with half the maintenance. We deliver the written decision, with the reason.
The algorithm, thresholds, states and persistence. The tests compile directly on the Mac and run in a few seconds. We deliver the suite and its result, not a promise of quality.
SwiftUI on iOS and macOS, or React Native when we have chosen shared code. We check the onboarding journey, permissions and behaviour when the sensor is missing or disconnects in the middle of the session — the case that often breaks in practice.
Bundle identifier, version, icons, privacy file, permission descriptions, team identifier from the Apple Developer Program. This is where projects that have not discussed the account from the start get blocked — including ours, which is exactly why we put this step on paper.
The data
The questions anyone with a data protection officer would ask — asked here before they do.
A case
The situation
A self-initiated project, not a client’s: a concentration timer that observes how much the head has tilted relative to a position calibrated by the user at the start of the session. I needed a case in which claims about the algorithm could be shown, not described.
What we built
I separated the core from the interface and wrote the thresholds in code, not in documentation: below 7° upright, between 7° and 13° slipping, above 13° held for three seconds triggers the haptic alert, with exponential smoothing at coefficient 0.15. The data come from Apple’s interface for the sensors in the headphones, with explicit handling of disconnection. The onboarding has 24 steps, of which four require confirmation of the limits before allowing the user to continue. From the same core I also built a macOS variant.
What came out
The logic suite compiles with `swiftc` and runs on Mac in a few seconds: 160 checks in 16 stages, all passed on the last run. The application installs and starts on the simulator. Any statement in the paragraph above can be verified by opening four lines of code.
What the case does not say
It is not in the App Store. The project configuration has an empty Apple team identifier, so the build cannot be signed for distribution — a lack of enrolment in the Apple programme, not a lack of functionality. And one more limitation, of the product not of the code: it measures head tilt, not spine health, and works with headphones that expose motion sensors through Apple’s interface.
Questions
No. None of our applications is in the App Store or Google Play, and it is right to ask that first. What we can show: five application targets defined in the same project, of which four for iPhone and one for macOS, which compile and install on the simulator, plus the 160-check logic suite, run on request in front of you. The publishing blocker is empty `DEVELOPMENT_TEAM` in the project configuration, that is, the absence of a team identifier from the Apple Developer Programme. On Mac there is a valid signing identity, of development type — enough for installation on your own device, not for the store.
If you ask for proof of publication, there is none and we do not invent one. What you can verify is the rest of the chain: code that compiles, tests that pass, privacy files present, declared permissions, icons and versions configured. The missing step is a paid enrolment in an Apple programme, made on the company that owns the app. In a client project, that account belongs to the client and is opened at the start, precisely so it is not the step that catches anyone by surprise at the end.
It depends on the sensors. If the app reads motion, health, Bluetooth or camera in real time, native — those interfaces belong to the platform and any intermediate layer adds delay and new ways to fail. If the app is essentially forms, calculations and result screens, a single codebase covers iOS, Android and browser from one repository. We have both options in our portfolio and we choose with a written argument, not by default.
Through shared code, yes: the same Expo project produces a build for Android, with the adaptive icon and the monochrome variant required by the system already configured. Native Android, in Kotlin, is not in our portfolio — if a project requires it, we say so before, not after signing.
By the fact that the core does not depend on the screen. The analysis files compile separately, with the Swift compiler, and run as a program on the Mac. The current suite has 160 checks in 16 stages and runs in a few seconds. What cannot be checked that way — how a vibration feels, how a screen looks on a particular phone, how the headphones behave when they come out of one ear — is tested on the device, and we say which is which.
Only if you approve it, type by type, in the Apple screen, and only the declared ones. In code, the policy is explicit for each kind of data: some stay only on the phone, others are read from HealthKit, others can be written back as a workout or a relaxation session. No diagnosis is made, and the data does not reach us.
It stays on the phone. In the reference iOS app from our portfolio there is no network call — searching for `URLSession` in the sources of that target returns zero results. The history is written to a local file and can be deleted from the app. When a project needs a server, we build it, but we do not add it as a reflex.
It starts with a compatibility check, not with an offer: which platform version it targets, which dependencies it has and which of them are still maintained, whether the build reproduces on a clean machine, who owns the developer account and the keys. There are projects where the honest answer is that rewriting the core costs less than maintaining it.
On macOS, yes, and from the same core: in our main repository the macOS target reuses fifteen logic files from the iPhone app, as shared sources. Windows is not in the portfolio.
10 of them are code and files from our repositories. We don't publish their name or line: together, on a single page, they would describe too precisely how systems that aren't only ours are built. We go through them with you, in the repository, on request — verification stays possible, it just happens in a conversation.
Tell us about your process. Together we decide what is worth building, what we can connect, and how we check the result.