Mobile App Developers near you

Cross-platform is usually the right default for a business app whose screens are lists, forms, dashboards and messaging, because most of the work is shared and one team can keep both versions in step. Native tends to win when the app leans hard on the camera, Bluetooth, background location, offline sync or heavy graphics, or when you want to adopt a brand-new operating-system capability the moment it ships.

Whichever the developer proposes, ask them to say why in terms of your app rather than their habits, and ask what happens when the two platforms disagree. Apple and Google diverge on notifications, account deletion, payments and privacy disclosure, and a proposal that pretends one codebase means one set of rules has skipped the part that causes rejections.

Apple's App Store Review Guidelines are organized into Safety, Performance, Business, Design and Legal sections, and several of the Legal rules bite on ordinary business apps. Apple requires a privacy policy link in App Store Connect and inside the app that identifies what data is collected, how, and every use of it; it requires user consent for collecting usage data; it tells developers to request only data relevant to the app's core functionality; and it requires that any app offering account creation also offer account deletion from within the app. Betas and demos are not allowed on the store, and submissions are expected to be final versions with working links and no placeholder content.

Google Play requires a Data safety declaration covering the data types the app collects and shares, the purposes, security practices such as encryption in transit, and whether users can request deletion. A privacy policy is required to complete the form. Google is explicit that the developer alone is responsible for making complete and accurate declarations, and that where it becomes aware of a discrepancy between an app's behaviour and its declaration it may take enforcement action, up to blocked updates or removal from Google Play.

Both stores put third-party code squarely on your side of the line. Apple tells developers to identify all of the data they or their third-party partners collect, and Google says data collection or sharing carried out by third-party libraries and software development kits must be reflected in your app's Data safety form. Analytics, crash reporting, advertising and support widgets all count, so ask your developer for a written list of every component in the build and what each one collects.

Insist that the app is published from your own organization's Apple and Google developer accounts, not the agency's. Apple enrols organizations as legal entities capable of entering into contracts, requires a D-U-N-S number, expects the person enrolling to have authority to bind the organization, and displays the organization's legal name as the seller on the App Store. If the developer enrols instead of you, their name is the one customers see, and your app sits inside an account you cannot log into.

Getting out later is possible but awkward. Google Play supports transferring an app between developer accounts through a formal request, and users, ratings, reviews, subscriptions and the store listing move with it, while things like earnings reports, test groups and integrated-service permissions do not. That is a manageable migration when everyone is friendly and a serious problem when they are not, which is the whole argument for starting in your own account.

On the code, get a written assignment of copyright signed by the developer, because the Copyright Act makes no assignment or grant valid unless it is in writing signed by the owner of the right. Cover the same ground for the pieces that are not code: the app signing and upload keys, the repository, the design files, and the credentials for the analytics, crash-reporting and push-notification services set up in your name.

Most of the variation between proposals is scope you cannot see from the outside. An app that only reads data is a fraction of the work of one that lets people create and edit it, and anything involving accounts, roles, payments, offline use or synchronisation between devices adds a layer of engineering that never appears in a screen count. Ask each developer to price the same written feature list, or you are comparing different products.

The other big drivers are the back end and the integrations. An app that talks to your existing systems inherits their quirks, and a developer who has not seen the other side of that connection is guessing. Ongoing work after launch, design depth, the number of platforms and whether you want automated testing all move the number as well. Where a quote is far below the others, the usual explanation is that it excludes the back end, the store submission work or the maintenance period rather than that someone found an efficiency.