Mobile app
development services
in Pasadena, California

Every autumn, Apple and Google ship a new major version of their mobile operating systems. For a team with an app in the stores, this is a fixed event on the calendar. It arrives whether the roadmap has room for it or not. Budgeting for it in advance is far cheaper than discovering it through a wave of crash reports.

The work starts months earlier. Both companies publish developer betas in late spring or early summer, together with notes on what is changing. Someone on the team should read those notes with this particular app in mind. Most changes will not matter. A few will, and they tend to be the quiet ones: a permission that now needs a new explanation, a background task that gets less time to run, a default setting that flips.

Install the beta on a spare device, never on the phone somebody relies on for work. Then walk through the main flows by hand. Sign in. Buy something. Receive a notification. Open a link from an email. Beta builds are unstable, so a failure is a reason to investigate rather than proof of a bug in the app code.

There are two separate questions here, and teams often blur them. The first is whether the existing app, built with the previous toolchain, keeps working on the new system. The second is when the app should be rebuilt against the new SDK. The first question is urgent. The second has a deadline set by the stores, usually with some months of slack.

Rebuilding with a new SDK changes behavior on its own. On Android, a build aimed at the new release inherits its stricter behavior for things like background work and edge-to-edge drawing. On iOS, recompiling can switch standard controls to fresh visual styles. Screens that looked fine yesterday may shift by a few pixels or change color. A visual pass over every screen belongs in the plan.

Then come the new features. Each release brings something the platform owner is keen to promote, from widgets to new kinds of alerts. Adopting them on day one is tempting, since the stores sometimes feature apps that do. Treat it as a product decision with its own value case. A shiny feature that few people open is a maintenance cost for a long time.

Third-party libraries add a dependency chain. A payment SDK, an analytics package or a map component may need its own update before the app can move forward. Check which vendors have announced support. If one of them is slow, the whole release waits.

People do not all upgrade at once. For weeks, and often much longer, the app will run on the new version and on several older ones side by side. Testing has to cover both ends. Dropping the oldest versions is a separate choice, made with real usage data from analytics rather than a hunch.

A sensible routine looks like this. Review the beta notes in early summer. Test the current build on the beta through the summer months. Ship urgent fixes before the public release lands. Plan the SDK upgrade for a quieter month afterwards. Written down once, this becomes a recurring line in the maintenance budget instead of an annual surprise.

Text entry is the slowest thing a person does on a phone. Every field in a mobile app costs more effort than the same field on a laptop. So the first question for any form is whether the field needs to exist at all. The second is how to let the phone do most of the typing.

Both platforms let the app declare what kind of data a field expects. An email field can bring up a keyboard with the at sign within easy reach. A phone number or card number field can open a numeric pad. A search box can show a search key in place of return. These hints take minutes to set and are skipped surprisingly often.

Autofill is the next layer. When fields are marked correctly as a name, a postal address, a username or a new password, the system can fill them from saved data. The password manager offers to store credentials after sign up and to suggest a strong password. Without those labels, none of this appears. The person types everything by hand, on glass, with one thumb.

One-time codes deserve particular care. When an app sends a code by text message, both iOS and Android can pick it up and offer it above the keyboard. On iOS this depends on the field being marked as a one-time code. On Android the app can use the SMS Retriever or SMS User Consent APIs, which avoid asking for broad permission to read messages. Getting this right removes a jump between apps at the most fragile step of registration.

The keyboard also takes up close to half the screen. Layouts must react when it slides in. The field being edited should stay visible, and the main button should not hide behind the keys. Check this on the smallest supported phone, where it breaks first. Check it again with a larger system text size.

Validation timing matters more on mobile. Showing an error after every keystroke is noisy. Waiting until the submit button forces people to scroll back and hunt for the problem. A calmer pattern checks each field when the person leaves it and places the message right beside it, in plain words.

Consider the return key as well. On a form with several fields it can move focus to the next one, and on the last field it can submit. Small detail. It turns a form into a sequence the thumb can follow without stretching to the top of the screen.

Some input should not be typed at all. Addresses can be picked from suggestions after a few letters. Dates work better with a picker than with free text. Card details can often be scanned with the camera, and wallets such as Apple Pay and Google Pay skip card entry entirely. Each of these is a small integration with a large effect on how the app feels.

When reviewing designs, ask the designer to mark the keyboard type, the autofill role and the next action for every field. It fits on the same spec sheet. Developers then have nothing to guess. The form reaches testing already behaving like one built by the platform itself. Testers can then spend their time on edge cases, such as pasted text, long names and accented characters, instead of basic keyboard complaints.

Most app briefs describe what the screen shows. Few mention what the phone does in the hand. Yet a short vibration after a payment, or a soft tick on a toggle, changes how solid an app feels. Haptics and sound are part of the interface. They deserve a line in the spec.

Both platforms offer ready-made haptic patterns tied to meaning. iOS has feedback generators for impacts, for selection changes and for notification events such as success, warning and error. Android offers haptic constants for actions like a key press, a long press, a confirmation or a rejection, plus richer effects on phones with better motors. Using these system patterns keeps the app consistent with everything else on the device.

The rule of thumb is restraint. Feedback should mark moments that matter: a completed action, a value snapping into place, a failed attempt. A buzz on every tap turns into noise within a minute. People stop noticing it, then start to resent it.

Match intensity to the event. A picker wheel ticking through values wants the lightest selection tick. A finished transfer can take a firmer notification pattern. An error should feel different from a success. The hand then knows something went wrong before the eyes check.

Hardware varies widely, especially on Android. Budget phones often have weak motors that rattle instead of tap. Some tablets have no vibration at all. The app has to ask what the device supports and fall back gracefully, and it should never rely on haptics as the only signal.

Respect the settings. People can switch system haptics off, and many keep the phone on silent all day. Sound effects in an app should follow the ringer switch or the media volume, depending on their role. A chime that ignores silent mode in a quiet meeting is one of the quickest routes to an uninstall.

Cross-platform frameworks need a closer look here. A single vibrate call in shared code often maps to a crude buzz on both systems. Good results usually come from a thin native layer that calls the proper platform patterns. Ask for it in the estimate. It costs little and is hard to add once dozens of screens call the crude version directly.

Sound has a narrower role than touch. It suits games, camera shutters, timers and alarms. It also helps in apps used with the eyes elsewhere, such as fitness or cooking. For banking or office tools, silence is usually the right default.

Accessibility points the same way. Haptics help people with low vision confirm an action, but they must not replace a visible or spoken message. Screen reader users already hear feedback from the system. Custom sounds should not talk over it.

Keep a short table in the design system listing each event, its haptic pattern, its sound if any, and the fallback. Developers wire it once as a shared helper. After that the whole app responds with the same touch. A new screen picks up the right feedback without another debate.