Mickael Romaniello
30 minutes, no slides, nothing to prepare.
Mickael Romaniello
30 minutes, no slides, nothing to prepare.
12 years of experience. 15+ apps delivered. One dedicated point of contact.
In short: I build iOS and Android apps for clients in San Francisco (873,965 residents) and across California. One single point of contact, 12 years of experience, delivery from concept to publication in 8 to 16 weeks.
I will tell you the truth, even when it's uncomfortable. That is the promise I make to all my clients from Cannes.
Creating an iOS or Android app takes time and money. So, no sugarcoating between us. With 12 years of experience under my belt, if your requirements are all over the place, I will pull the brakes.
The most important factor: I am here to make sure your investment actually serves your users. That is how we build great applications.
You have an app idea.
If your target audience in San Francisco expects premium quality, your choice of platform matters.
The most important factor is knowing where the value is.
iOS users spend 2x more in-app than Android users.
The Apple ecosystem attracts a customer base that is used to paying for quality, subscriptions, and premium services.
If you want to build an iPhone app in San Francisco that generates solid revenue, you need to target the App Store.
But be careful. You do not just walk into Apple's store easily.
You have to respect their rules. Their design standards. Their technical requirements.
I am a freelance iOS developer.
My job is not just writing lines of code.
Everyone wants their app on the Apple store.
But publishing an iOS application is a real journey.
The key advantage of this complex process is that it filters out bad apps.
First, there is the creation of the Apple developer account. And here comes the surprise.
If you are a business in San Francisco, you need a DUNS number.
The DUNS is the international ID card of your company.
Getting it can take between 2 and 4 weeks. It is best to know this on day one.
Then, we code. Cleanly. Following the rules.
Next comes the testing phase with TestFlight.
TestFlight is the rehearsal room for your application.
We can invite up to 10,000 testers before the official release.
This is where we hunt down bugs and tweak the experience.
Finally, the final boss: validation by the App Store.
Keep in mind that nearly one submission in four is rejected.
A poorly filled privacy form. A poorly explained paid option. A missing test account.
Apple lets nothing slide.
Validation takes between 24 hours and 7 days.
This is why having an iOS expert in San Francisco is not a luxury.
I know these rules by heart.
My goal is to help you avoid frustrating back-and-forths with Apple reviewers so your app goes live as quickly as possible.
San Francisco is the one place where I am usually not the first developer someone has spoken to, and often not the first to have written code for the idea. Inheriting a half-finished app is a different job from starting one — the first week goes on reading what exists and telling you honestly which parts are worth keeping.
That week is not billable padding, it is the most valuable week of the project. There are really only three verdicts. The code is sound and undocumented, in which case we keep it and I write down how it works. The code is unsound but the data model is right, in which case we keep the database and rebuild above it, which is far cheaper than it sounds. Or the foundations are wrong, in which case the honest answer is to start again, and hearing that early costs you a week instead of a quarter.
The hardest part of that conversation is usually not technical. Someone has already paid for the existing work, and "start again" sounds like admitting the money was wasted. It usually was not: the existing version taught you what the product should be, which is exactly what a first attempt is for. But sunk cost is a poor reason to keep an architecture that will slow every future change, and I would rather have that argument in week one than deliver a build that stays fragile forever.
The nine-hour gap is real and shapes how we work. Our days barely overlap — your early morning is my evening. That suits a project with defined weekly deliverables you review at your desk and I act on the next day. It suits badly a project that needs live discussion to make progress. I will tell you which of the two yours is before we start, because getting that wrong wastes a month for both of us.
The number one fear when starting an app project is losing control: you sign an estimate, hand over your idea, and hear nothing for three months. The way of working described here exists so that does not happen.
Three rules, the same on every project:
You test the app on your own phone every two weeks.
With Invent Better you get an installable build every two weeks, even when it is incomplete. That is the difference between following a project and waiting for one. You have access to the code repository from day one, and every decision is written down rather than remembered. A disagreement surfaces after two weeks, not at final delivery.
Software development is far too often treated as a terrifying black box.
In many traditional projects, you sign a massive specification document, you pay a hefty deposit, and then you just wait. For months, you receive nothing but vague updates. A few reassuring emails. A lot of "trust us, it is coming along great."
And then the day of the final big reveal in San Francisco arrives... and your heart sinks. The product looks and feels nothing like what you envisioned. But it is entirely too late, and your budget is completely gone.
The most important factor: when you work with me, that black box simply does not exist. Everything is entirely transparent.
Publishing an app with Apple requires anticipating their strict rules.
Spoiler: we do not discover the constraints at the end of the project.
The key point is to prepare the groundwork from the start.
First, the design.
We validate together that your idea respects Apple's guidelines for your target audience in San Francisco.
Then, the administrative steps.
You need an Apple Developer account. And a DUNS number to open it under your company name.
While the paperwork processes, I develop.
This is the intensive coding phase in Swift and SwiftUI.
Very quickly, we move onto TestFlight.
This is Apple's app that allows you to install test versions on your own phone.
We can even invite your first testers in San Francisco to gather their feedback before release.
Next comes the App Store Connect stage.
This is the dashboard where we configure your App Store listing.
We must fill out the privacy labels (what the app tracks or not) with surgical precision.
Finally, the submission.
Know that nearly one submission in four is rejected.
If this happens, do not panic.
We analyze the Apple reviewer's feedback, fix the blocking issue, and resubmit.
We move forward step by step until the official publication.
Take a common case: a fitness app sold on subscription.
Their business model relied entirely on converting free users into paying ones.
In short, the Apple ecosystem was the perfect target.
Why? Because iOS users spend 2x more in-app than Android users.
We built the application around a seamless integration of Apple Pay and StoreKit.
If the payment screen looks scary, the user leaves.
They click. They quit. They forget.
We made subscribing as simple as a double-click on the iPhone's side button with Face ID.
However, Apple scrutinizes subscriptions closely during review.
Apple processes 100,000+ app submissions per week and mercilessly rejects apps with unclear pricing terms.
I designed the paywall screens in strict compliance with App Store rules to avoid any rejection.
The launch was an immediate success.
The conversion rate exceeded expectations, proving that in San Francisco as elsewhere, a well-designed iOS app is a highly profitable machine.
A native iOS app generally costs noticeably more than a web or hybrid equivalent. The reason is Apple's standards: its design rules demand care on every screen, button and animation, and App Store review rejects what does not meet them. That extra cost mostly buys a smaller chance of being rejected.
This is the question everyone in San Francisco asks.
Let's be clear: a native iOS application generally costs noticeably more than a web or hybrid app.
Why?
The most important factor is Apple's high standards.
Apple's design rules require special care for every screen, every button, every animation.
We cannot cut corners.
Then, there is the preparation for the Store.
nearly one submission in four is rejected.
To avoid this, I spend time ensuring the code is perfect, privacy policies are clear, and all crashes are resolved on TestFlight before publishing.
This preparation and quality time comes at a cost.
Excellence requires work.
There are also Apple's fixed fees.
The choice of platform also depends on your industry.
The key advantage of iOS is that it offers powerful native tools for certain sectors.
This is the king domain on iPhone.
With HealthKit, the app can read steps, heart rate, or sleep recorded by the Apple Watch.
This is a level of integration impossible to replicate elsewhere.
But beware, nearly one submission in four is rejected and Apple is uncompromising on health data management.
If you sell high-end goods in San Francisco, the iPhone is essential.
Apple Pay allows the user to pay with a glance using Face ID.
Zero forms to fill out.
They click, they pay.
Not to mention integration with Apple Wallet for loyalty cards.
The main argument here is security.
The Apple ecosystem is closed. There are fewer viruses and gaping flaws than on other open systems.
For an app that handles money in San Francisco, the "Available on the App Store" badge immediately reassures the client.
Not always, which is good news for the budget. An app that only handles its own user's data — a list, a tracker, a calculation — can keep everything on the phone and cost nothing to run. As soon as data has to be shared between people, synced across two devices, or seen by you on your side, a server is needed, and that is a cost that comes back every month.
It depends entirely on what was decided at the start, and it is one of the few choices that cannot be postponed. An app can keep its data on the device, let people work, then sync as soon as the network returns — with nobody pressing anything. It is essential the moment work happens in a warehouse, a basement, or on the road. Added afterwards, it often means rewriting half the app.
We pick a floor, and that choice has a price. Supporting older OS versions means more testing and giving up some capabilities. We look at who your users are: a consumer app and an internal tool deployed on a known fleet do not get the same answer. The floor can be raised later, when usage data shows nobody is left behind it.
It matters more than people think, because a heavy app is the first uninstalled when storage runs short. The weight rarely comes from the code: it is the bundled images and fonts. Loading images from the server rather than shipping them, and serving them at the right size, often halves it. That is invisible work, and it is the work that keeps the app installed.
Technically, sending costs almost nothing. What costs is everything around it: a server to decide what to send to whom and when, and enough care not to become intrusive. It is also the easiest mechanism to waste — a useless notification is the first cause of uninstalls, and an uninstalled app does not come back. Send few and make them useful, or send none.
Yes, with the user's permission, and how you ask matters as much as the feature. A permission demanded on first launch, with no context, is refused most of the time — and once refused it is painful to recover. Asked at the moment the person understands why, it is granted. Apple also requires a written explanation for every permission, and a vague one gets the app rejected.
Through the stores, and not instantly: Apple and Google review every version before it is published, and phones update at the pace of their own settings. So expect a share of your users to stay on an older version for weeks. That is why the server has to keep talking to previous versions, and why we avoid changes that break everything at once.
Often yes, and it all hangs on one thing: does your vendor provide a documented API. If they do, it is ordinary work. If they do not, or bill it per module, or refuse to open it to a third party, no app will work around that cleanly — workarounds exist and break at the vendor's next update. It is a question to put to your supplier before you put yours to me.
A website can be installed on the home screen, work offline and launch full-screen, with no store involved. It is a real third answer, and it is under-recommended because it earns less for whoever recommends it. Its limits: notifications stay restricted on iPhone, sensor access is partial, and you are not present in the stores — which matters if your customers look for you there.
Only if you have an audience in another language — and then it has to be designed in, not added on. Translation is not what costs; room is. German makes labels half again as long and overflows buttons drawn for English. Leaving room from the start costs nothing; redoing the screens afterwards costs days. The legal texts and the store listing count too.
While you hesitate, your competitors in San Francisco are moving forward.
The mobile world moves fast. Very fast. Today, most global web traffic comes from mobile devices. If you keep pushing back the creation of your app, someone else will happily take your spot in California.
But be careful, do not confuse speed with haste. Launching an unstable application is the worst possible strategy.
In short: you have to act fast, but above all, you have to do it right. ⏳
30 minutes to start
Book →Most of my projects run remotely, and in practice that changes very little. We talk over video whenever you need to, not only at major milestones, and you can reach me with questions at any point during the project — I always answer.
Once we are working together, travelling to meet you on site can absolutely be arranged if your project calls for it. Travel costs are quoted separately, upfront and with no surprises.