Apps come in all shapes and sizes these days. Having an understanding of how apps are developed will help with understanding what it takes to have a successful app that engages users and keeps them coming back for me. We spend a lot of days in our studio working through scenarios, wireframes, and architectures of app builds we’re working on.
Platforms, to be Native or Hybrid
Apple (iOS) and Android are the obvious players here. Windows and Blackberry, while maintaining some of the market share are the ugly duckling in the conversation. We’re going to skip over those two since we do not develop for them. iOS and Android have fundamental differences right from the get go—they’re native programming languages are different. Developing native apps enables full access to all of the phones internal capabilities and UI elements. There’s a huge intrinsic benefit to going this route—there are literally no limitations. The flip side of that coin is that there must be two different core sets of code written to satisfy the developing on both iOS and Android, which then equates to much higher development costs. We’ve touched on the costs of development in a prior post, but in short, this is how you see development builds for larger more capable apps well in excess of $100k.
Another more tactful approach depending on the scope of the project is to develop a hybrid app. These apps use a web view inside of a natively programmed container and allow developers to use standard programming languages like HTML, CSS, and JavaScript frameworks. Hybrid apps, when done well are completely transparent to the user and no one could tell the difference since virtually all of the same internal OS architecture is still accessible. Also, the hugest factor when developing with hybrid apps is that the code set is the same for iOS and Android and that friends is a beautiful thing.
API Development, Communication is Key
OK, so you have a killer app, but now what? How do you handle user registration, in-app sales, pulling existing information from your website, and really any outside data? The answer lies in an API—Application Programming Interface. APIs allow for access to data that doesn’t live internally within the app. That can come in the form of real-time weather data, updating a user’s information in a database, you name it, and APIs can do it.
Merisign builds our own custom APIs to handle the functionality of every project that goes out the door. It’s how we can make sure the information securely gets from point A to point B, which definitely don’t get to an SSL installed on your server. Encryption is money well spent. API’s when accessing outside information are generally easily deployed, but reapplying the acquired information within your app is a different story and can be more time consuming. It’s a necessary evil, though. An app without access to outside information is largely useless.
Distribution, You Have an App?
Both app stores make the actual distribution pretty simple. You have the respective stores and the processes to get your app in front of potentially millions of users. What are the basic steps to make that happen?
- First order of business is getting proper provisioning profiles in place. Apple will not allow you to publish an app without these profiles in place. Once you’re accustom to the process, it’s really not so bad, but they can certainly be at the least a small roadblock for a first timer.
- After the provisioning profiles are in place, you can begin the process of uploading screenshots, writing descriptions, establishing country distribution, and cost structures.
- Next is the approval process. Depending on the capabilities, complexities, and current reviews ahead of yours, really dictates the timeline. Google is virtually always faster than Apple in their review times, but you should account for at least two days and keep your fingers crossed it does not take longer.
- After this, it’s simply a waiting game. Time to reward yourself with a cocktail and enjoy the fruits of your labor.
OK, the siesta is complete. Your app is now in the store. How in the hell do you plan on getting the exposure you need to find success? Great question and there are some consistent courses of action. First off, paid apps always have a cost hurdle to get over. We get it, apps take a long time to build and you need to be compensated for the investment of time and money to make this digital dream a reality, but let’s face it, the average consumer does not know what they do not know.
Marketing your app outside of stores is key. Touching people’s lives in a tangible way always helps. Having a dedicated website to market your app’s capability is a must. A simple one pager can be the difference of a download or not. Users want to know what they’re getting, so having a video showing the apps functionality can also make a solid first impression. These are just some of the grass roots, non-paid forms of marketing that we’ve seen success with.
Future Compatibility, Maintenance for Future Success
Crap, the latest OS just came and now your app doesn’t work anymore. It’s a reality and your developer should be in the loop on future releases and testing for compatibility. Sometimes all is good and others it’s not. It’s no different than with websites. A new version of WordPress arrives on the market and all of the sudden there are PHP errors on people’s sites. It’s a reality of the fast-paced world of software development we live in. Staying on top of things is what’s important. Trusting that your development team is on the ball is everything. Formal maintenance agreements are the best way to handle these scenarios. Then there is a fair equitable scenario for all parties.
Go forth and build awesome stuff
Sure the app stores are saturated, but we applaud all that develop beautiful and highly functional apps. Needs spark ideas and that is where things start. Consult your local developer for insight on how they feel is best to proceed with bringing an idea to market.