Development:
"The app development process can be broken out into four major parts – idea, layout and planning, design, and going live.
1. The Idea
This is the first genesis of where the app will be going and one step after “I want an app.” Looking the app store, there are dozens of different directions you can go – simple information, a game, interactive, etc. You can imagine that the more complicated it is, the more it’s going to cost – but also a higher chance at getting a return on investment. Games are complicated, but can go viral easily. Simple apps don’t do much, but they are cheap and easy to build. The first step of the process if to find your sweet spot of budget and marketing effort.
2. Functionality Layout
It’s not enough to paint the broad strokes for a programmer, because they’re not going to deliver what you want. You need to either invest a lot of your own time to go through the details or find someone who can translate Programmer to Civilian and vice versa. This will pay off big time in the end. This step involves going through every single screen and understanding how all parts of the app interact with each other – If I press this button, what happens? You will be amazed how many steps and scenarios there are for even the simplest app. The amount of functionality that needs to be defined and built will also play a part in the cost of your app.
3. Design
Unlike websites where you can often get someone who can design and code at once, apps usually require a team of people to complete. The nice thing about this is that the designer can be graphics, print, web, or whatever – the deliverables to the programmer will be images that he just pops into the appropriate areas. The design comes in typically once the programming and functionality have been defined – the designer gets a full list of what needs to be created. Design can make or break an app, plain and simple, so don’t skimp on this. You need a great icon, splash screens, tab icons, and dozens of other assets that need to be tied together.
4. Going Live
Once you have the app built in xCode (the program that apps are built in for Apple), your developer can help you get the app in the store (iTunes for this example). This requires setting up an iTunes Connect account ($99/year) and then filling out all the information necessary for the app – icons, descriptions, pricing, etc. Most of this is pretty intuitive one you get the files loaded, and a lot of it can be done by your technical team. The setup is also a one time thing, so if you decide to develop another app later on, you already have an account you can dump it into.
Once you have the app up in the store, you can monitor all the analytics on the back side of it through iTunes Connect – how many downloads, how much $$ you are making, etc. There are lots of different ways to drive revenue with apps, including advertisements inside the app and being able to purchase additional information through the app (in-app purchases). You can see everything happening. You can also have someone monitor this account the way you would have someone monitor your PPC or SEO campaigns so that you are always maximizing your traffic and revenue." [1]
Distribution:
Android :
"On Google Play, you can publish your products to customers instantly. Just upload and configure your product in theGoogle Play Developer Console and press the Publish button—your app appears in the store listings within hours, not weeks.
Once your app is published, you can update it as often as you want. You can change prices, configuration, and distribution options at any time through the Google Play Developer Console, without needing to update your app binary.
Later, as you add features or address code issues, you can publish an updated binary at any time. Google Play makes the new version available almost immediately and notifies existing customers that an update is ready for download. To streamline the rollout across your customer base, Google Play also lets users accept automatic updates of your app, so that your updates are delivered and installed as soon as you publish them." [1]
[2]ISO (Apple):
"App Store
The revolutionary App Store experience makes it easy for you to reach millions of iPad, iPhone, and iPod touch customers. The App Store is accessible through Wi-Fi and cellular networks so customers can discover and download your apps wherever they go. And once a user has downloaded your app, they will be notified whenever you post an update — directly on their iPad, iPhone, or iPod touch.
Ad Hoc Distribution
With Ad Hoc distribution, you can share your app with up to 100 iOS devices via email or your server." [3]
Web vs Native:
"1. Native apps
If you’re designing a service or utility (task-based) app that requires real speed and you want to use the native features of the OS running on a given device, then for now your best bet is to code a native app, think Instagram.
2. Web apps
In other words, apps that live entirely online and run in a web browser tab. If you don’t need the native features associated with iOS or Android, say, and the purpose of your app is primarily information-based – to the extent it needs constant communication with the server – then you’re better off building a web app. An example of this would be Forecasthttp://forecast.io/, the weather app built using HTML5. No need to go to the app store, just search, download to your home screen and you’re good to go. Forecast also puts to bed any assumptions that a native app interface is de facto better. As Forecast themselves say, it’s more a question of users getting familiar with the progress that’s been made:
“It’s 2013, and mobile browser technology has advanced tremendously in the past few years: hardware accelerated transforms and animations have made it easy to create perfectly smooth, jitter-free, interfaces..”
3. Hybrid apps
As the name suggests: a native app, but built using HTML, CSS and Javascript. This speeds up the development process and makes it easier to publish across platforms, but there can be compromises in styling and performance. Netflix is a good example of one that works: using the same code base for its user interface on all devices allows Netflix to change the interface or conduct testing at will (whilst video streaming is done within the native layer, meaning it feels fast and ‘native-like’ to the user).
In short, each of the approaches here have a role, it depends on what we’re trying to achieve. For marketers, I’d wager we default to a native app too quickly. The question to ask is “will this app provide genuine utility or entertainment that users will want to return to of their own accord in future?” If the answer is closer to “no, this is a short term campaign to promote a product launch” then let’s do everyone, including our CFOs, a favour and build a light, responsively designed web page instead." [1]
[2]
No comments:
Post a Comment