Resonance chamber
DROMMEX LTD has built mobile applications for years, for iOS and for Android. The work runs from the first description of behavior through design, build, testing, release, and the updates that follow a release. Every product is made for both platforms. There is one shared plan, carried into two shells, and a release is not finished while one of those shells is still a guess.
Inside the apps, an assistant can talk with the person using them. It is not a human, and it is not professional advice. What someone writes is used only to answer that person, and it is not passed to other users. The apps build no personal profile, and users do not send personal data to each other. Attribution uses Singular. Push notifications use OneSignal. The only identifying item is a unique id.
iOS and AndroidEvery product is built for both.
One shared planBehavior is written once.
One unique idSingular and OneSignal, nothing else.
Push specimenslides in
The same actions are specified for iOS and Android before either shell is drawn.
OneSignal delivers the notice. The only identifying item on it is the unique id.
A reply is prepared for the person who wrote. It is not passed to other users.
Singular receives that same unique id. No second identifier is added for the other platform.
02 — Both heads
A mobile product that exists on only one platform is an unfinished plan. We describe the behavior once, then build the shell each operating system actually expects. The intent does not fork when the icon does.
The iOS shell keeps the navigation stack, the type, and the review rules of that platform. Screens are tried on the phone sizes people hold, not on a single golden frame. Release means a build prepared for the App Store, with notes that match the binary.
Haptics, sheets, and permission prompts stay with the system. We do not invent a private layer on top of them just so the two apps look like twins in a screenshot.
Android keeps its back behavior, its own type ramp, and the spread of screens we agree to support. We do not shrink an iOS picture and send that to the other store. Release means a build prepared for Google Play and checked against the same behavior list.
System back, notification channels, and background limits are part of the design, written down before the build, and tested on device with the iOS pass still in view.
03 — The sequence
Years of this work have settled into a fixed order. We do not start by painting screens, and we do not stop at the first binary a store accepts.
We write the actions, the empty states, the failures, and the sentences the assistant is allowed to say. Both platforms inherit this list. If a flow is unclear here, it is not ready to be drawn.
Layout, type, contrast, and touch targets are decided for a thumb and a short session. iOS and Android are designed in the same pass, each in the shell its system expects, from the same behavior list.
Engineering follows the list. Platform code differs where the operating system differs: navigation, back, type, and permissions. The plan stays one plan, reviewed against the behavior notes rather than against a mood.
Flows are run on devices. That includes the main task, the assistant’s replies, the arrival of a push through OneSignal, and the screens that must hold up on a poor connection. A pass on one platform does not clear the other.
Each store gets its build, its notes, and the checks that belong to that platform. We do not ship one side and leave the other as a follow-up with no date. The strike is both releases, prepared together.
Fixes, copy, and changes to the assistant go out on a train. Both platforms are on that train on purpose. An update that lands on only one store is treated as unfinished work, not as a completed release.
04 — Shell notes
The two shells are not costumes on one picture. Each keeps the habits of its system. The task list, the assistant’s limits, and the unique id stay shared.
Stack and indicator
Back and system bar
iOS
A stack pushes and pops. Large titles appear where they help a person know which level they are on. The edge swipe is the system’s, and we do not cover it with a custom gesture that fights it.
Android
System back is part of the flow, including the predictive back the platform provides. We do not hide the task behind a private history that the system button cannot leave.
iOS
Type follows the iOS ramp and the Dynamic Type sizes we commit to. Targets stay large enough for a thumb, and contrast is checked on the device, not only in a design file.
Android
Type follows the Android ramp and the font scale the system exposes. The same actions are reachable, with targets and contrast checked on Android hardware rather than inferred from the iOS build.
iOS
The App Store build carries notes that describe the binary. Review questions are answered from the behavior list, so the words and the app do not drift apart during the wait.
Android
The Google Play build is prepared in the same release window. Store listing copy is checked against the same list, including any change to the assistant’s wording.
iOS
OneSignal delivers the notification on iOS. The copy and the destination are planned once. The address OneSignal uses is the unique id, not a name or an email.
Android
OneSignal delivers the same class of notice on Android, with the channel and importance that platform requires. Again the address is the unique id. People cannot push notes to each other.
iOS
Singular records the install and the open against the unique id, so a campaign can be tied to an install. Singular is not given a name, a phone number, or a precise location by these apps.
Android
The Android install reports through Singular with that same kind of unique id. We do not add a second identifier so the two stores can be reconciled. One id is the whole identifying item.
05 — Chamber rule
It does not travel to the next person, and it does not become a profile.
That is the rule under the craft. The apps do not ask for a name, an email, a phone number, contacts, or a precise location, and they are not built to store them. Users do not send personal data to each other. There is no directory of people and no handle to search. Singular handles attribution. OneSignal handles push. A unique id is the only identifying item. The assistant speaks to one person at a time. It is not a human, and it is not a professional you can lean on for advice.
06 — The repertoire
The line below is the job. If a capability is on it, it is part of how an iOS build and an Android build leave the studio. Nothing on the line is a claim about awards, ratings, or a count of installs.
07 — The reply
The apps include an assistant a person can talk with. It answers inside the app. It is not a human sitting behind the text, and it is not professional advice — not medical, legal, financial, or any other kind that needs a qualified person. If a question needs that person, the assistant is the wrong place to ask it.
What someone writes is used only to produce the reply they see. Those words are not passed to other users. They are not assembled into a personal profile, and they are not a back channel between people who happen to use the same app. The specimen on the right shows the limit in plain language: a refusal of advice, and a refusal to carry the message onward.
The same limit ships in the iOS build and the Android build. A later update can change the wording. It does not change the rule that a reply belongs to the person who asked.
Person
Is this pain something I should worry about?
Assistant
I am not a person, and I cannot give professional advice. I can only talk about what is inside this app.
Person
Do other people see what I type here?
Assistant
No. Your words are used to answer you. They are not passed to other users, and they are not kept as a profile.
Specimen only. A reply is generated for the person who wrote, then it stops.
08 — The room
The privacy note states this in full. The short version is structural: two providers, one identifier, and no portrait of the person holding the phone. Read the note before you write to the studio about data.
Attribution uses Singular. An install or an open can be tied to a campaign through the unique id. Singular is not handed a name, an email, a phone number, contacts, or a precise location by these apps.
Push notifications use OneSignal. The unique id is how a notice finds the install. One person cannot use that path to place a message on another person’s screen.
The only identifying item is a unique id. It exists so Singular can attribute and so OneSignal can deliver. It is not a name, and it is not an email address you typed into the app.
The apps build no personal profile. They do not ask for your name, email, phone number, contacts, or precise location, and they have no field whose job is to keep those facts.
Users do not send personal data to each other. There is no profile to find and no path that carries one person’s words into another person’s app.
The assistant is not a human and not professional advice. Messages are used only to reply to the person who wrote them, and they are not shared with other users.
09 — Next strike
Write with a question about a build, the assistant’s limits, or this site. Mail opens in your own client and goes to the developer named on the card. Read the privacy note and the terms if the question is about data, Singular, OneSignal, or what the assistant is allowed to say.