Loading...
Answers
MenuIs it better make sure your app is 99.99% complete before submitting it to apple for review? Or do you finish the last 10% with updates?
This is my first app project. My off-shore developers seem eager to submit my app to the app store, and tho I know there are some changes I would like to make I am inclined to want to see app live, if only to see that it really works....
Answers
In my opinion, the best thing to do is to finish the development completetly, test your final product for bugs and when the teating period is over you can go ahead and publish it.
Best regards,
For more details I'm always available.
For starters, I don't think there is such a thing as perfect code. You're always going to discover (and hopefully squash) bugs along the way. Apple might roll out an update for iOS and complicate things. Perfection will always be just out of your reach. That being said, I keep a dedicated QA tester on call to ferret out all known bugs and quirks. We test and iterate until the app is as perfect as it can be. Only after my tester has performed regression testing and verified that all known bugs have been fixed do we submit the app for review. Then, once it's in the hands of real people using real devices, I can learn how good a job we've done. They tell me what they want or what doesn't make sense. You'll always want to release regular updates—if only because it's good for your marketing—and you'll want to save development dollars for future development phases during which you add significantly to the codebase. So for your first project, I wouldn't let your developers' eagerness influence the timeline. Only submit for review after you're confident that the current version of the app works flawlessly, but keep in mind that you'll have plenty of time to make more changes. And hopefully, your new revenues will pay for those changes!
Cheers,
Austin
I am assuming you are referring to a bug free app and when you say 99.9% you're referring to the % of functionality implemented as opposed to the quality level. Then I would say go live. I think Reid Hoffman's quote (founder of linked in) sums it up best. "If you're not embarrassed by the first version of your product, you launched too late."
Get something out in the market that gives you some idea if there is even a demand for the product you are producing. Not all good ideas are successful and the feedback you receive could even send you down another road, possibly saving you time and money building a product that no one wants.
Get that minimal viable product (MVP) out there, collect lots of data (analytics and feedback), learn and hustle.
If you want to read up on Lean start up philosophy and techniques buy Eric Reis book "Lean start up".
If you need any further assistance feel free to give me a call
Steve
It really depends on the type/functionality of the application.
If the app is quite small and you miss out on providing the core feature set to the user, then that will not be a good user experience. In this case you should get 99% (you can never be 100%, there's always more you can do) before you launch the app. On the other hand, if the functionality you plan to leave out does not hinder the core user experience, but possibly provides a value-add on top, that is something you can add later with an update.
Also, if it is a game which has several levels/stages, you can add more levels and stages later and provide the user enough to play with version 1 to keep them busy till the next version launches.
Remember, generally the last 10% of fixes in an app take over 50% of the time, so you want to make sure you are not bogged down with minor tweaks and fixes if they do not hinder the user's experience in using your app.
From a review standpoint, Apple will accept your app provided that the functionality you have implemented already is functional and free of obvious bugs. Assuming you've achieved that, then this becomes a business question. You've made some assumptions in creating your app about what users want. Is it better to get the app out to real users and find out if those assumptions are correct? Or would you rather make sure your assumptions are really polished even if they might be wrong? To me, the question is rhetorical.
If the core of your app is the way you want it and you'r enot planning on a huge (aka expensive) PR/media campaign on launch, just submit it.
First release is nowhere near a finished product. You will discover plenty of user requests, feedback and bugs. You should never develop a product in a "closed room".
However, there is also a discrepancy in your numbers… Is it missing 0.01% or 10%?? :)
Glad to talk details (meaning specific features) to better help you.
PS beware of a team that might be trying to close the project due to "hidden" issues.
Figure out what your minimum working platform should look like and develop that at 100%. All the extras and bells and whistles can come in updates. But if the platform does not work (aka WW2 Online, where you couldn't fire the guns...oops) do NOT put it out. You won't have anyone left waiting for the updates.
Related Questions
-
Whats are some ways to beta test an iOS app?
Apple will allow a developer to register 100 UDID devices per 12 month cycle to test via TestFlight or HockeyApp. Having started with TestFlight, I would really encourage you NOT to use it, and go directly to HockeyApp. HockeyApp is a much better product. There is also enterprise distribution which allows you far more UDID's but whether you qualify for enterprise distribution is difficult to say. As part of your testing, I'd encourage to explicitly ask your testers to only register one device. One of the things we experienced was some testers registering 3 devices but only used one, essentially wasting those UDID's where we could have given to other testers. Who you invite to be a tester should be selective as well. I think you should have no more than 10 non-user users. These people should be people who have either built successful mobile apps or who are just such huge consumers of similar mobile apps to what you're building, that they can give you great product feedback even though they aren't your user. Specifically, they can help point out non obvious UI problems and better ways to implement particular features. The rest of your users should be highly qualified as actually wanting what you're building. If they can't articulate why they should be the first to use what you're building, they are likely the wrong tester. The more you can do to make them "beg" to be a tester, the higher the sign that the feedback you're getting from them can be considered "high-signal." In a limited beta test, you're really looking to understand the biggest UX pain-points. For example, are people not registering and providing you the additional permissions you are requiring? Are they not completing an action that could trigger virality? How far are they getting in their first user session? How much time are they spending per user session? Obviously, you'll be doing your fair share of bug squashing, but the core of it is around improving the core flows to minimize friction as much as possible. Lastly, keep in mind that even with highly motivated users, their attention spans and patience for early builds is limited, so make sure that each of your builds really make significant improvements. Happy to talk through any of this and more about mobile app testing.TW
-
What tools to use for mobile Prototyping ?
My 2 favourite are: - www.uxpin.com - www.flinto.com Flinto is by far my favorite for mobile. I also us www.balsamiq.com for anything wireframe. Sometimes I jump into Sketch http://www.bohemiancoding.com/sketch/ for more high fidelity mockups using their Mirror feature http://www.bohemiancoding.com/sketch/mirror/ Hope that helps. P.S. There's a tonne of Mobile UX experts on Clarity, many $1/min - call them, you'll learn so much. my2cents.DM
-
Does the 30% apple transaction fee apply to physical goods purchased on an app? Really need help Struggling Startup!
Apple specifically precludes anything that can't be delivered via the app from using in-app purchases. So you're free to tie a credit-card to services and real-world fees (think Uber) without paying Apple any transaction fees. Here's Apple's documentation on what they support (and don't allow) for in-app purchases. https://developer.apple.com/in-app-purchase/In-App-Purchase-Guidelines.pdf Happy to help in any way I can. I run a mobile-based startup myself.TW
-
If I am planning to launch a mobile app, do I need to register as a company before the launch?
I developed and published mobile apps as an individual for several years, and only formed a corporation later as things grew and it made sense. As far as Apple's App Store and Google Play are concerned, you can register as an individual developer without having a corporation. I'd be happy to help further over a call if you have any additional questions. Best of luck with your mobile app!AM
-
Where can I find programmers willing to join a growing mobile start up for equity only?
You won't find anyone worth adding to your team willing to work for equity only, no matter how compelling your product and business is. The realities of the talent market for mobile developers anywhere is such that a developer would be foolish to work only for equity unless they are a cofounder and have double digit equity. Happy to talk about hiring and alternatives to full-time hires.TW
the startups.com platform
Copyright © 2025 Startups.com. All rights reserved.