Author: Rob@Kumulos

NSDateFormatter Online Guide

nsdateformatter online guide

This blog post has been produced for one simple reason: to save you time.

The number of times we hear of iOS developers hunting to locate the NSDateFormatter string, scrolling through miles of content on unicode.org was getting a little disheartening, so we decided to make this easy and get it in a blog.

Bookmark it, memorise it, share it with friends or link to it. A simple resource that comes in handy.

Date formats for iOS 6+, OS X 10.8+

Field Sym. No. Example Description
era G 1..3 AD Era – Replaced with the Era string for the current date. One to three letters for the abbreviated form, four letters for the long form, five for the narrow form.
4 Anno Domini
5 A
year y 1..n 1996 Year. Normally the length specifies the padding, but for two letters it also specifies the maximum length. Example:

Year y yy yyy yyyy yyyyy
AD 1 1 01 001 0001 00001
AD 12 12 12 012 0012 00012
AD 123 123 23 123 0123 00123
AD 1234 1234 34 1234 1234 01234
AD 12345 12345 45 12345 12345 12345
Y 1..n 1997 Year (in “Week of Year” based calendars). Normally the length specifies the padding, but for two letters it also specifies the maximum length. This year designation is used in ISO year-week calendar as defined by ISO 8601, but can be used in non-Gregorian based calendar systems where week date processing is desired. May not always be the same value as calendar year.
u 1..n 4601 Extended year. This is a single number designating the year of this calendar system, encompassing all supra-year fields. For example, for the Julian calendar system, year numbers are positive, with an era of BCE or CE. An extended year value for the Julian calendar system assigns positive values to CE years and negative values to BCE years, with 1 BCE being year 0.
U 1..3 甲子 Cyclic year name. Calendars such as the Chinese lunar calendar (and related calendars) and the Hindu calendars use 60-year cycles of year names. Use one through three letters for the abbreviated name, four for the full name, or five for the narrow name (currently the data only provides abbreviated names, which will be used for all requested name widths). If the calendar does not provide cyclic year name data, or if the year value to be formatted is out of the range of years for which cyclic name data is provided, then numeric formatting is used (behaves like ‘y’).
4 (currently also 甲子)
5 (currently also 甲子)
quarter Q 1..2 02 Quarter – Use one or two for the numerical quarter, three for the abbreviation, or four for the full name.
3 Q2
4 2nd quarter
q 1..2 02 Stand-Alone Quarter – Use one or two for the numerical quarter, three for the abbreviation, or four for the full name.
3 Q2
4 2nd quarter
month M 1..2 09 Month – Use one or two for the numerical month, three for the abbreviation, four for the full name, or five for the narrow name.
3 Sept
4 September
5 S
L 1..2 09 Stand-Alone Month – Use one or two for the numerical month, three for the abbreviation, or four for the full name, or 5 for the narrow name.
3 Sept
4 September
5 S
l 1 (nothing) This pattern character is deprecated, and should be ignored in patterns. It was originally intended to be used in combination with M to indicate placement of the symbol for leap month in the Chinese calendar. Placement of that marker is now specified using locale-specific <monthPatterns> data, and formatting and parsing of that marker should be handled as part of supporting the regular M and L pattern characters.
week w 1..2 27 Week of Year.
W 1 3 Week of Month
day d 1..2 1 Date – Day of the month
D 1..3 345 Day of year
F 1 2 Day of Week in Month. The example is for the 2nd Wed in July
g 1..n 2451334 Modified Julian day. This is different from the conventional Julian day number in two regards. First, it demarcates days at local zone midnight, rather than noon GMT. Second, it is a local number; that is, it depends on the local time zone. It can be thought of as a single number that encompasses all the date-related fields.
week
day
E 1..3 Tues Day of week – Use one through three letters for the short day, or four for the full name, five for the narrow name, or six for the short name.
4 Tuesday
5 T
6 Tu (OS X 10.9+ & iOS 7+)
e 1..2 2 Local day of week. Same as E except adds a numeric value that will depend on the local starting day of the week, using one or two letters. For this example, Monday is the first day of the week.
3 Tues
4 Tuesday
5 T
6 Tu Tu (OS X 10.9+ & iOS 7+)
c 1 2 Stand-Alone local day of week – Use one letter for the local numeric value (same as ‘e’), three for the short day, four for the full name, five for the narrow name, or six for the short name.
3 Tues
4 Tuesday
5 T
6 Tu Tu (OS X 10.9+ & iOS 7+)
period a 1 AM AM or PM
hour h 1..2 11 Hour [1-12]. When used in skeleton data or in a skeleton passed in an API for flexible date pattern generation, it should match the 12-hour-cycle format preferred by the locale (h or K); it should not match a 24-hour-cycle format (H or k). Use hh for zero padding.
H 1..2 13 Hour [0-23]. When used in skeleton data or in a skeleton passed in an API for flexible date pattern generation, it should match the 24-hour-cycle format preferred by the locale (H or k); it should not match a 12-hour-cycle format (h or K). Use HH for zero padding.
K 1..2 0 Hour [0-11]. When used in a skeleton, only matches K or h, see above. Use KK for zero padding.
k 1..2 24 Hour [1-24]. When used in a skeleton, only matches k or H, see above. Use kk for zero padding.
j 1..2 n/a This is a special-purpose symbol. It must not occur in pattern or skeleton data. Instead, it is reserved for use in skeletons passed to APIs doing flexible date pattern generation. In such a context, it requests the preferred hour format for the locale (h, H, K, or k), as determined by whether h, H, K, or k is used in the standard short time format for the locale. In the implementation of such an API, ‘j’ must be replaced by h, H, K, or k before beginning a match against availableFormats data. Note that use of ‘j’ in a skeleton passed to an API is the only way to have a skeleton request a locale’s preferred time cycle type (12-hour or 24-hour).
minute m 1..2 59 Minute. Use one or two for zero padding.
second s 1..2 12 Second. Use one or two for zero padding.
S 1..n 3456 Fractional Second – truncates (like other time fields) to the count of letters. (example shows display using pattern SSSS for seconds value 12.34567)
A 1..n 69540000 Milliseconds in day. This field behaves exactly like a composite of all time-related fields, not including the zone fields. As such, it also reflects discontinuities of those fields on DST transition days. On a day of DST onset, it will jump forward. On a day of DST cessation, it will jump backward. This reflects the fact that is must be combined with the offset field to obtain a unique local time value.
zone z 1..3 PDT The short specific non-location format. Where that is unavailable, falls back to the short localized GMT format (“O”).
4 Pacific Daylight Time The long specific non-location format. Where that is unavailable, falls back to the long localized GMT format (“OOOO”).
Z 1..3 -0800 The ISO8601 basic format with hours, minutes and optional seconds fields. The format is equivalent to RFC 822 zone format (when optional seconds field is absent). This is equivalent to the “xxxx” specifier.
4 GMT-8:00 The long localized GMT format. This is equivalent to the “OOOO” specifier.
5 -08:00

-07:52:58

The ISO8601 extended format with hours, minutes and optional seconds fields. The ISO8601 UTC indicator “Z” is used when local time offset is 0. This is equivalent to the “XXXXX” specifier.
O 1 GMT-8 (OS X 10.9+ & iOS 7+) The short localized GMT format.
4 GMT-08:00 (OS X 10.9+ & iOS 7+) The long localized GMT format.
v 1 PT The short generic non-location format. Where that is unavailable, falls back to the generic location format (“VVVV”), then the short localized GMT format as the final fallback.
4 Pacific Time The long generic non-location format. Where that is unavailable, falls back to generic location format (“VVVV”).
V 1 uslax The short time zone ID. Where that is unavailable, the special short time zone ID unk (Unknown Zone) is used.

Note: This specifier was originally used for a variant of the short specific non-location format, but it was deprecated in the later version of this specification. In CLDR 23, the definition of the specifier was changed to designate a short time zone ID.

2 America/Los_Angeles The long time zone ID.
3 Los Angeles The exemplar city (location) for the time zone. Where that is unavailable, the localized exemplar city name for the special zone Etc/Unknown is used as the fallback (for example, “Unknown City”).
4 Los Angeles Time The generic location format. Where that is unavailable, falls back to the long localized GMT format (“OOOO”; Note: Fallback is only necessary with a GMT-style Time Zone ID, like Etc/GMT-830.)

This is especially useful when presenting possible timezone choices for user selection, since the naming is more uniform than the “v” format.

X 1 -08

+0530

Z
(OS X 10.9+ & iOS 7+)

The ISO8601 basic format with hours field and optional minutes field. The ISO8601 UTC indicator “Z” is used when local time offset is 0. (The same as x, plus “Z”.)
2 -0800

Z
(OS X 10.9+ & iOS 7+)

The ISO8601 basic format with hours and minutes fields. The ISO8601 UTC indicator “Z” is used when local time offset is 0. (The same as xx, plus “Z”.)
3 -08:00

Z
(OS X 10.9+ & iOS 7+)

The ISO8601 extended format with hours and minutes fields. The ISO8601 UTC indicator “Z” is used when local time offset is 0. (The same as xxx, plus “Z”.)
4 -0800

-075258

Z
(OS X 10.9+ & iOS 7+)

The ISO8601 basic format with hours, minutes and optional seconds fields. The ISO8601 UTC indicator “Z” is used when local time offset is 0. (The same as xxxx, plus “Z”.)

Note: The seconds field is not supported by the ISO8601 specification.

5 -08:00

-07:52:58

Z
(OS X 10.9+ & iOS 7+)

The ISO8601 extended format with hours, minutes and optional seconds fields. The ISO8601 UTC indicator “Z” is used when local time offset is 0. (The same as xxxxx, plus “Z”.)

Note: The seconds field is not supported by the ISO8601 specification.

x 1 -08

+0530
(OS X 10.9+ & iOS 7+)

The ISO8601 basic format with hours field and optional minutes field. (The same as X, minus “Z”.)
2 -0800
(OS X 10.9+ & iOS 7+)
The ISO8601 basic format with hours and minutes fields. (The same as XX, minus “Z”.)
3 -08:00
(OS X 10.9+ & iOS 7+)
The ISO8601 extended format with hours and minutes fields. (The same as XXX, minus “Z”.)
4 -0800

-075258
(OS X 10.9+ & iOS 7+)

The ISO8601 basic format with hours, minutes and optional seconds fields. (The same as XXXX, minus “Z”.)

Note: The seconds field is not supported by the ISO8601 specification.

5 -08:00

-07:52:58
(OS X 10.9+ & iOS 7+)

The ISO8601 extended format with hours, minutes and optional seconds fields. (The same as XXXXX, minus “Z”.)

Note: The seconds field is not supported by the ISO8601 specification.

Full documentation:

OS X v10.9 and iOS 7 – http://www.unicode.org/reports/tr35/tr35-31/tr35-dates.html#Date_Format_Patterns

OS X v10.8 and iOS 6 – http://www.unicode.org/reports/tr35/tr35-25.html#Date_Format_Patterns

 

Older versions:

iOS 5 – http://www.unicode.org/reports/tr35/tr35-19.html#Date_Format_Patterns

OS X v10.7 and iOS 4.3 – http://www.unicode.org/reports/tr35/tr35-17.html#Date_Format_Patterns

iOS 4.0, iOS 4.1, and iOS 4.2 – http://www.unicode.org/reports/tr35/tr35-15.html#Date_Format_Patterns

iOS 3.2 – http://www.unicode.org/reports/tr35/tr35-12.html#Date_Format_Patterns

OS X v10.6, iOS 3.0, and iOS 3.1 – http://unicode.org/reports/tr35/tr35-10.html#Date_Format_Patterns

OS X v10.5 – http://unicode.org/reports/tr35/tr35-6.html#Date_Format_Patterns
OS X v10.4 – http://unicode.org/reports/tr35/tr35-4.html#Date_Format_Patterns

How to Make Sure your App Services Meet Customer Needs

customer-development

If you look at app development in a simplistic way, it’s easy to end up with a rather straightforward life-cycle for an app project:

  • Win the business.
  • Work with the customer to build the app to their satisfaction
  • Get it “out the door” and into the app stores.
  • Get paid and move onto the next thing.
  • Perhaps earn some follow-up revenue if the customer comes back for changes.

Plenty of app development firms work in exactly this way, but it doesn’t take a genius to see that it’s actually rather short-sighted and reactive. It’s also a way of doing business that attracts spells of feast and famine – times scrabbling around for the next project and times when too many jobs are happening at once.

It’s actually pretty simple to adapt your app business so that you can approach things from a far more proactive stand-point. This means more revenue, happier customers, and a more consistent workload for your team, with fewer peaks and troughs.

Here’s a five step guide to better molding your services around customer needs:

1. Break free from the “job and finish” model

It may require a change in perspective, but it’s important to get away from the mind-set where an app project begins when the customer signs the contract and ends when the app hits the stores. In reality, this really isn’t the way; building an app isn’t the same as building a house.

Once you’ve broken out of this way of thinking, it will become natural to explain things to customers in the right terms. Version 1.0 of an app is just the start of the journey if the app is to be in any way successful.

 2. Explain that the project’s not over when the app is built

Once an app is live, there’s still plenty to do. Apps need promoting so that people actually use them, for a start. Then, there’s the fact that however well you’ve tested things, bugs can and will inevitably come to light once more people are let loose on the app.

It’s imperative that someone keeps an eye on user reviews and deals with support queries too, as this can help expose bugs and reveal misunderstandings as to how the app is supposed to work.

All this is just the start. The important thing is that customers understand this fact!

 3. Manage expectations regarding ongoing work

It’s one thing making clients understand that there’s more to “having an app” than building it and releasing it, but clients do need to know what to expect financially. They’re not likely to give you a blank check or an open-ended contract!

However, this doesn’t mean you shouldn’t be up-front about telling them what to expect in terms of ongoing costs. Often, companies have no problem spending money when the reason is well explained to them – what they don’t like is unexpected or unclear invoices. Or having this news sprung on them right at the end of the project. Lay it out up front for them and explain that’s just the right way to approach an app to make it succeed.

So, build app updates into your plan; tell customers how frequently they’re likely to need to issue bug-fix releases; and make clear what kind of money they’ll need to spend – not just to get the app “out there,” but to get people actually using it. One of the best approaches is to explain that you work “Lean” and that focusing first on an Minimum Viable App is the most cost effective approach, with subsequent releases prioritized around how the app is actually getting used.

This benefits all concerned: the clients know what to expect, and you lay out a long-term stream of ongoing revenue you can rely on.

4. Understand your client’s business

If you’ve read this far, it’s probably becoming clear that the general objective is to aim for more of a partnership relationship with your clients than one that’s focused around selling a one-off service.

If you’re going to make this work in the long-term, it’s essential that you really start to understand your client’s business.

This has long been a problem for techies of all kinds. IT technicians and developers “working in isolation from the business” is a frequent management complaint, and often a very valid one.

If you are able to separate yourself from this (often all-too-true) stereotype, and make it your business to learn the priorities and objectives of the companies you work with, you really will stand out from the pack. Really getting under the skin of your client and understanding their business and what they need their app to achieve will mean more trust, more work from your clients, and more referrals.

5. Proactively suggest improvements

Really, this leads on from the last point, but you cannot truly deliver here unless you first understand the business of your client(s).

Once you do, you’ll easily be able to merge your technical knowledge and your knowledge of the app marketplace with your knowledge of the customer’s company – and inspiration for app improvements will surely follow.

By keeping the ideas flowing, you will be able to ensure your clients stay focused on the ongoing development of their app – especially if you can suggest ways to boost their revenue. Ideas that are obvious to you may not occur to people removed from the app scene, so don’t underestimate the value of your inspiration.

Keeping an app business customer focused isn’t rocket science, but it is something plenty of firms get wrong. One of the easiest ways to do this is through a monthly App Report. Discussing regularly how the app is performing and suggesting areas where improvements in the app can be made is one of the best ways to drive improvements in the app, and ongoing revenue for your business.

By going back to basics and getting it right, you can form long-term partnerships that continue to please the customer AND make you money – long after version 1.0 has landed in the app store.

Further Reading

Found this useful, then these related articles could also be of interest.

Ask the Right Questions

To really understand your clients needs its about asking the right questions up front. Here’s 20 questions you should make sure you get answered up front to make sure your the app project succeeds for you and your client.

Take an iterative approach to save your clients money and time

Agile development methodology and shipping your first app as an MVP is all about getting the app into the hands of users as fast as possible and then in short time iterate the development of the app to optimize how its performing. There’s no replacement to the real world.

Top Mobile App Developers Los Angeles

Top Mobile App Developers Los Angeles

Here at Kumulos we understand that finding the best mobile app development company to work on your project can be tough. There’s no one size fits all here. It’s about right sizing and finding the right mix of abilities to fit your project.  So to help, we’re reviewing the Top Mobile App Developers Los Angeles. If you’re looking for a top mobile app developer further north, check out our of San Francisco based app developers.

Having reviewed dozens of different mobile development agencies from Diamond Back to Venice Beach and beyond, we’ve painstakingly selected the top players in the LA area to help point you in the right direction. We have deliberately chosen a range of companies in this review; from specialist mobile app development businesses to broad-line digital agencies that can help you position your new mobile app within a broader digital strategy.

So here’s the ones we like. They make our Top Mobile App Developers Los Angeles list in alphabetical order. We’ll be adding more to the list as we continue our research.

1. Citrusbits

best app developer San Francisco Citrusbits is an innovative mobile app development agency serving Los Angeles, San Francisco Bay Area and Eagle Rock. The company has a great website and video outlining their position in the market. With a strong focus on quality, Citrusbits is driven by passion, excellence, persistence and focus. The company’s website explains how Citrusbits like to ‘code differently’ and it’s clear they’ve worked with some top clients. Having developed 100+ apps for the likes of Quicksilver, Valet Tax and Assay Technologies. The company is run by Ammad Khan (Managing Consultant), Zack Afridi (Head of Marketing) and Arrione Garcia (Director of Operations).

You can follow Citrusbits on Twitter

2. Dreambox Creations

best mobile app developers San FranciscoIf you are looking for a full service digital agency that can integrate your mobile app with in a broader digital strategy then Dreambox Creations is worth a look. Located 30 miles from downtown Los Angeles in Diamond Bar, Dreambox Creations Dreambox Creations offers everything you would expect from a full service digital company, working closely with many of the most popular restaurants and eating facilities in the USA and further afield. Dreambox Creations work with some of the biggest names in the restaurant industry including In-n-Out Burger, San Diego University and Yard House. The key company players include Dan Bejmuk (CEO and Co-Founder), Adrian Cheung (Digital Media Strategist) and Danielle Takata (Owner).

You can follow the Dreambox Creations Team on Twitter

3. Innoppl

best mobile app developers San FranciscoInnoppl Inc is a market leading mobile & web application development firm based in LA. The company develops and deploys mobile apps designed to cater specifically to Los Angeles-based customers. Innoppl cover mobile apps for native iOS iPhone, Android, and mobile-web HTML5. The company also develops apps across numerous vital sectors including healthcare, automotive, retail, startups, education and much more. The company’s clients include the likes of Outside Television, Sherwin Williams and Mighty Auto Parts. The key company players are Nash Ogden (President), Pon Pandian Paulswamy (Technical Architect) and Kumaran Parthiban (Senior Technology Consultant).

You can follow the Innoppl team on Twitter

You can check out the Innoppl video below on “How to set a Mobile App budget for 2016’:

4. ISBX

best mobile app developers San FranciscoBased on Sepulveda Blvd, ISBX is an award winning mobile development agency with over a decade of experience. The company offer a wide array of digital marketing and mobile app technology services which includes creative branding, user experience, mobile and web development, platform testing as well as (and most importantly) helping app publishers launch and market their new applications.  They do this for some of the biggest global brands. ISBX work closely with clients to define their commercial goals and develop appropriate strategies to deploy enterprise class apps for clients. In 2014, ISBX presented at the Mobile World Congress (GSMA) in Barcelona, Spain and was recently acknowledged in publications including Inc 500 and the Los Angeles Business Journal. The key company players are Eric Wise (President founding partner at ISBX), Kelly Chu (Chief Technology Officer founding partner at ISBX) and Arthur Iinuma (Chief Operating Officer and founding partner). ISBX has worked with some seriously impressive clients including Nike Air Jordan, Warner Bros and Sony Pictures. If you’re looking for the Top App Developers LA these guys could be ones to watch.

You can follow the ISBX team on Twitter

5. Neon Roots

best mobile app developers San FranciscoNeon Roots are first and foremost a software development business that develops mobile apps as one of their core services.  The company focuses heavily on unlocking value in marketing and business development for their customers. Neon Roots goal is not to build the most elaborate, feature rich mobile app possible. Instead the company takes an alternative approach by focusing on developing apps that deliver against their clients commercial objectives. We like that, we like that a lot. Adopting a data driven, agile development approach to mobile app development, Neon Roots work with customers to test, refine, and validate at a conceptual level using real market/user data. The key company players are Ben Lee (CEO and Founder), Drew Harding (COO and Founder) and Kellan O’Connor (Venture Advisor). Neon Roots client roster includes the likes of American Idol, Epson and Snoopify.

You can follow the Neon Roots team on Twitter

I love LA

So now you’ve got a laser like insight into the top mobile app developers Los Angeles scene.

Doing mobile well is tough because there are a tonne of things you need to consider before you engage the right app development agency. You need to think about the requirements of your project, develop wireframes, API specs and user stories. You’ll also need to consider analytics, MBaaS, push notification platforms, app store optimization and a whole plethora of things before you get your project started. The great thing is, once you have a keen understanding of what your project KPI’s and success measures are, you’ll be ready to rock and hopefully one of the agencies listed above could be the perfect match for your project.

Stay tuned to the blog as we’ll be adding more mobile development companies in LA. If you’re an app developer from the Los Angeles area and you reckon you should be considered for our shortlist, or know of any who would, drop us a line!

20 questions to ask your client before you build their mobile app

20-questions-ask-client

So your business builds mobile apps for a range of business clients. That’s a great place to be right now. Lots of opportunities. Lots of potential projects coming your way. When we talk to busy mobile app development businesses they tell us one of their biggest challenges is getting the mobile app build project properly scoped. Too many times projects become too organic with new requirements emerging through the life of the project, sometimes too many ideas on what the app should do and they find it difficult to really define what success looks like.  What we’ve found is that if you can get good insight into the project by getting answers to these 20 questions right at the start of the project, its more likely to be a success, both for the client, and for the mobile app agency.

And, when the mobile app is developed and live in the app stores, you need to think about how the app is performing. Mobile App KPIs are so important and yet often they are not defined clearly.  To help, we’ve also pulled together the 10 questions you have to answer in order to track the right mobile app KPIs.

Firstly, it usually starts with your new client coming to you with a great idea for a mobile app that will help revolutionize their business and reach out to existing customers and a whole new set of customers. That’s awesome!

A project that starts off in the right direction has more chance of ending up in the right place, so here’s 20 questions you need answers to before you start that mobile app build.

Can you summarize the Mobile App to me in just a few sentences?

This isn’t to catch the customer out, it’s to really see how well they understand the “essence” of the app. For example, are they also planning to use app analytics to send segmented push notifications. The better they understand it, the more confident you can be that they will be very exact and focused about what the app needs to do, who its focused at, how they will use it etc. This is also your chance to explain to them how you can build in crash reporting and API endpoint monitoring to keep the app running smoothly.

Who are the target users?

What problem is your app going to solve for them? Why is a mobile app the best way to solve this? Could a mobile responsive website be just as good, or an even better way to solve the problem? What devices or platforms are they most likely to use, there are real demographic differences between android and iOS platforms that need to be thought through. This is also your change to explain how you can help with app store optimization (ASO).

What’s the real deadline?

Is it linked to any other activity (a big product launch) or tied into a seasonal campaign? So it’s usually the case that the project should have started yesterday.  But at least you can work out what’s possible with the time you have. Work back through AppStore submission, multi-platform testing, development, and creative, ideation to set the expectation early on what’s practical, and what’s not, in the time you’ve been given.

What risks are there with the mobile app build?

What are the outside dependencies that could affect the timescales? Addressing this up front will save you a lot of problems further down the track. Building a risk register as part of the project kick-off and being disciplined to keep this up to date is a good idea, even for what seems to be a simple app product. Make sure that for each risk there are actions and owners responsible for managing down the risk of this affecting your successful app delivery.

What’s the budget?

So the game usually is, we don’t have a fixed idea of a budget, we want as much as we can get for as little as we need to pay. Mobile projects are really difficult to budget estimate, but for you to scope the project you need at least to work to a range. Defining the scope of work is also really important. It not just about the physical build. Is there budget for researching the app, competitors, key functions that users will highly value that will guide you on what the first release (or minimum viable product) NEEDS to have for the app to be market ready. If it’s a new client it could become a tricky game of poker, neither side wanting to show their hand, but unless you get to a range pretty quickly, expectation management is going to be tricky. If the client can’t give you a range, that could be a red flag, it may not be a serious project but just a vague idea they are trying to flesh out.

You should also agree what the ongoing budget is going to be once the app is live. There will probably be hosting costs, ongoing optimization of the app, on-boarding and in app use, discovery optimization, push notification services you should be offering – as well as managing scaling out back-end systems as app user grows.  Knowing how much ongoing work the app will require could also influence how much you charge in the initial build phase. You could decide to scale back costs on the initial build and get the app to market quicker, then work with the app owner to continually improve the app over time. They get an awesome app that’s just getting better and better. You build long term income streams for your business and long term relationships with your clients.

Who are the key Stakeholders?

Is this who you are working with, or are their others that you need to know about? Who is the budget holder? Who is the Project Owner? Your contact, or someone else. What are the decision making stages? Who need to be consulted at what stage to move from Ideation, to prototype, to build, to test, to release? Who are you going to work with post launch? Is there a formal process here (you should hope there is), or is this a more organic process, and if so its point 1 on your Risk Register, in big, bold, black ink capitals.

What does success look like at each stage of the process?

Building this into a number of smaller phases, with approval “gates” you need to go through may sound bureaucratic and feels like it could show you down, but it will, without doubt, save you time, money and a lot of anxiety through the mobile app build.

What are the business objectives for the mobile app?

Is the mobile app an internal app to increase workforce efficiency? Is it there to open the product or service up to a new profile of user? Will it increase sales from existing customers? All good, worthy reasons to build an app. Answers to this question will have a huge influence on how you build the app, what the core features and functions of the app, what platforms it needs to run on and what analytics and Key Performance Indicators (KPIs) you need to track once the app goes live.

Who will the app compete with?

Has the client done a detailed evaluation of competitors in the space that you can work from? Don’t accept the response – “We don’t have any competitors here, we are the first to do this?” It’s a common response, but one that’s usually not true. There may be no direct competitors doing EXACTLY the same thing, but that doesn’t mean that there aren’t other ways that people are solving the problem that they have. This shouldn’t be an App to App comparison. So ask the question “how do the future users of your app currently solve this problem?” that way you’ll probably get a more insightful answer.

What design considerations/constraints does the Mobile App have to work within?

Are there corporate guidelines that the mobile app layout and screen designs need to conform to? Will this work on a mobile format? Are there constraints on how it can appear in the app store. Will this tell you how the icons in the app store need to look? Will this limit how the app will pop-out at someone browsing the store? What scope is there to push back on the branding police to get some design latitude to let you do an awesome job?

Is there scope to have multiple releases?

This is both in terms of what native platforms you need to build on as well as functionality. Is it possible to focus on a minimum viable product (MVP) as version 1 release,  with a feature roadmap?  Does it have to be big bang with all features on all platforms day 1.  This may be desired, but is it REALLY a necessity. Even if you need to go Big Bang, its still good to work with the client to define and agree what the minimum viable product (MVP) NEEDS to be. That will help focus discussions around the budget and timescales for launch.

What is the backlog of functions for the app?

Even if you’re not using an agile software development approach to building the app, getting your clients to build a backlog of (non MVP features) is a very powerful way to get them to prioritize between the essential functions of the app and those that are non-core for version 1 release. This has the other benefit of helping you plan future releases for the app, important for App Store discovery optimization (ASO) and managing your future project work (and cash flow).

What are the underlying assumptions?

Is it to work across tablets and mobiles? Can this be one version that resizes or do you need a build for both?  How back compatible does it have to be , iOS8 and later, Android 5.0? Android 4.0?. Does the app need to work offline? Will it have to connect with wearables or Internet of Things devices? What languages is the app going to be built in? The answers you get to “Who are the target use of the app?” will obviously have an influence here.

How is it going to be hosted?

Is there an existing infrastructure it needs to plug into? What are the security protocols? Are there any upstream micro-services that need (or would be good to) plug into the app? Is there going to be a website (mobile responsive of course) that will sit along-side the app and have to share user profile information etc.? Are there any other vendors that the app needs to integrate with (salesforce, SharePoint etc). How are you going to manage user generated content and what’s the expected upload/download shape of that content? Take the complexity away from building and managing the server side of your app with an industry leading mBaaS tool.

What are the data points that your client will need to get from the app?

Baking the measures, metrics and benchmark objectives into the mobile app at the design stage will help make sure that the mobile app build phase delivers against the key measures of success. If you don’t define the key metrics, that underpin the tangible measures of success for the app at outset, how will you focus the decision on MVP features? Also mapping out the analytics and metrics during the build will save the agony of trying to retro-fit these late in the day, or worse be duped into judging the success of the app based on what’s easy to measure, rather than what are actually the true measures of success.  Core to this should be measures of recency, frequency, duration & lifespan.

Clients want to know

  • How many downloads?
  • On what platforms?
  • Ratio of push notifications activated?
  • How many that download are actually fully installing?
  • How many active users you have (is this growing)?
  • What features are being used the most?
  • Where are the dead areas of the app that need re-thought?
  • How frequently is the app being used?
  • For how long (use session length)?
  • How many transactions (sales) have completed?

Mapping the actual against expected, looking at the variance then working a plan to close the gap between actual and plan is what it’s all about. As long as these are defined up front of course. You’ve got a huge role to play here, and a huge opportunity to generate on going monthly recurring revenue from the initial app project to help the owner of the app optimize and improve the commercial performance of the app.

What is the monetization strategy for the app?

If it’s a B2E app, solving internal problems for a business to improve staff productivity, then there is still a money angle and a Return on Investment business case. If it’s designed to increase revenue for the business, how is it going to do that? in app purchases?, subscription model?, will features be unlocked with staged payment?, is a physical or virtual product being delivered after payment (so do you need logistic tracking)?, will there be in app advertising to monetize traffic through the app? Knowing this and building the app around the business goal will keep the client focused. Agreeing the MVP and building the Backlog of features acid testing each feature and function against the business goal will mean you’re focused on doing the important things in priority order.

How will they buy?

Different from monetization. How do they physically pay for the product or service within the app, credit card, biometric payment (ApplePay and the like). Depending on the answer, you need to be thinking about security/encryption and device compatibility the app must work on.  So testing regimes, influence that Native vs Hybrid decision, security & data encryption etc.

Are there other apps that the client likes that can be used as inspiration for how this new app should look?

This isn’t about copying or plagiarizing someone else’s design, this is about using completely unrelated apps to help get you into the head of your client and understand how they are thinking. It’s easier if your following an already predefined UI/UX design and corporate guidelines, but it’s still important to do this, if only to help you decide how essential it is to build a native app so it accesses all the rich handset functionality.

How is the app going to be found when it’s ready to go live?

If it’s a B2E app, this may not be that important, but for B2B and B2C apps getting found in GooglePlay and the AppStore is going to be important to draw users to the app. Don’t think this is an afterthought. Its not. You have to think of this at the design and development stage. Make sure it conforms to design guidelines of each store it’s listing in, if it doesn’t follow the rules its going to be tricky to get it listed. You’ll also need a good app store optimization tool to ensure you’re targeting the right keywords. Carefully think about future releases, as this has a huge influence on discovery. An App that’s continually being developed will rank better in the store. Also make the icon impactful so it communicates the value and purpose of the app is really important. And don’t discount video. Including a short video demonstration of your app will have a huge impact on driving download conversions from your app store listing page.

What about post launch? What’s the ongoing plan to learn & improve?

There needs to be one, right?

No matter how awesome you are as a mobile app development agency you’re just not going to get everything right first time. You’re also probably not going to be able to deliver all the features your client wants, within the budget they have to spend and the timescale you’re presented with. The clients going to be very very focused on the first delivery point, getting the mobile app live. That’s natural. But your job is to coach them to think longer term. Get them to think about the MVP, and getting them to build the backlog creates the mind-set that this is an ongoing project. The first phase is version 1. This means you get them thinking early about the ongoing phases of releases as well as the promotion of the app.

Making sure that there is good data coming from the app is also critical. In addition to crash reporting & diagnostics, using data & analytics to know how the app is performing particularly focusing on recency, frequency, duration and lifespan. Getting your client to predict up front what is the expected “Norm” and tracking variance from that will help your and your client prioritize the remedial work that will be needed to get the app downloaded, used, and reused frequently.

Bonus Question – Question 21

So lastly, and consider this as a bonus question, given we are through the 20 questions promised in the title.

What dependencies are there, that we need to consider before we can get started with your new app?

It’s good if you can get the client to clearly tell you what needs to happen before they sign the work order and kick the project off. Do you need to run an ideation workshop (to make sure an app is actually what they need)? Does a purchase order need to be signed off by the budget-holder? Are you both covered by a Confidentiality & Non-Disclosure agreement? In short, what are the barriers to starting this project in the next hour?

20 Questions to Ask your Clients to make your app project a success

Of course, no set of questions will be the same for every project and every client and every mobile app use case. Hopefully this gives you good coverage of the main points. If you would like a handy reference guide, why not download the Guide with 20 questions you need answers to – before you build your client’s mobile app.  Asking the questions, documenting the answers and playing these back to the client in the format of “You Told Us This… so we will therefore do that” will make sure you are both on the same page. Better this than stumbling in to bear-pits through the project.

There’s also another free, confidential mobile app project scoping tool that you could benchmark your customer app project against.

What about your questions?

OK, so we’ve given you a bunch of questions to ask your client, but what about when you have questions about your mobile app business? No worries – we’re here to help. That’s why we’ve started a FREE business webinar series that addresses many of the questions that app development agencies have in mind.

The webinars are intended for Business Owners, CEO’s, Sales & Marketing VP’s and Commercially minded CTO’s. They’re 100% business focused, so they’ll give you ideas on how to drive more retainer based income for your Mobile App Development Business.

Feel free to look at some of our past webinars, or take a gander at some of our upcoming sessions. These webinars are popular and seats are limited, so be sure to register early. Or, just contact us and we’ll be happy to answer your mobile app development questions.

About Kumulos

The Kumulos platform started life as a hosting and API management system to help build and manage the server side of the mobile app. It’s now evolved into the most comprehensive mobile app performance management platform for mobile app agencies with Push Notifications, In-app Messaging, App Store Optimization, App Analytics, Crash Reporting & API Endpoint Monitoring, Document sharing & Collaboration and Content Editing all in one place. Why not take a look at who uses Kumulos?

But that’s not all. It comes with a number of unique, turn-key features, custom built to help busy mobile app agencies offer services to their client. Services that help keep the dialogue flowing, so they stay close and win regular follow up client work. And the best bit, services that the agency charges monthly for, so they get more app projects on monthly retainer, once the app goes live.

We don’t care whether you’re building native apps on iOS and Android, or using your preferred hybrid platform, or a low-code / no-code platform, you can use Kumulos to help you deliver greater commercial success. We partner with a range of technology providers so you can have it your way.

Ask for a tour, or start your free trial today!