Anna and Apple Watch

Apple Watch- a Mother’s Perspective

The Apple Watch has arrived. With a bit more fanfare than the Google Watch. Three identical white boxes housing the watch. Seriously, Apple? Apple product designers have taken their fetish for minimalism – but not utilitarianism, ironically – to a new level. After unboxing, then unboxing, then unboxing again, I tried to start it up and was disappointed. This was vastly different than my first wearable, the shuffle, and how simple and direct that was to get started. No, I had to sift through instructions and read online, then figure out that my phone hadn’t the right app, and my appleID was wrong, then read some forums on what others did, then finally, figured out how to sign up under the proper AppleId. It was a downer. I don’t have a unique AppleId problem, if you’re wondering. Just writing AppleId so many times makes me cranky. more…

Beta Testing on Both Platforms – Android and iOS


1. Upload your APK to the Beta tab of Google Play’s developer console.
2. Create a community in Google Plus, and invite your users.
3. Add the link to the community page to your Beta.
4. Click on “invite testers” and you will receive a link to the app on the play store- but just for testers (it has “testing” in the path).
5. Email your users, and emphasize that they should click this link on their device- obvious but bears pointing out- and give it a few hours.


1. Upload a release version of your app to the Prerelease tab on iTunesConnect. This requires an almost complete store profile.
2. Submit it for approval (still in pre-release mode, will not be public).
3. Add external testers in the “prerelease” tab of iTunesConnect, for your app.
4. Invite them.
Note: there is potentially more complexity to this that I will detail in another blog post. This is the best case scenario- that has actually worked for me. For internal alpha users, yes, that was buggy as of a month ago.

Both methods are key to getting a good set of beta testers. I used to use TestFlight for both Android and iOS, and those were great days. Both platforms are now more advanced than old TestFlight, with crash reports and better user management. Apple still has some kinks to work out but it worth it for a nice process that doesn’t require device Ids.

Also, checkout the bug I found: using Gmail to check for app invitations results in errors. More: here.

Don’t Use Gmail- And Other Random Tips to Using iTunesConnect + TestFlight

The integration of TestFlight services into iTunesConnect has been bumpy. Here are some troubleshooting tips:

1. Don’t Use Gmail To Accept Invitation


If you’re having issues getting your AppleId to work in an Internal tester of iTunesConnect- don’t use Gmail to launch TestFlight, nor accept the initial invitation.

To slow it down…

iTunesConnect’s implementation of TestFlight requires that you have an AppleId. Many of us have several, or we don’t want to use our personal one. So, you can create a new one, such as, “banane+atf”… subdomain your Gmail email. Problem is, when you get the link from TestFlight, and click on it to accept the invitation to your app, it will forward you through a strange loop, or, just fail. I kept getting TestFlight with my personal AppleID, and no apps displayed.

This is fixed if you don’t use Gmail to access your email from Apple. Just forward it to another mailbox. Yep. Then, clicking on the button will accept your user and you will see your app added.

2. Add Contact Email To Build Each Time

Each build you upload- click on the Build, click on TestFlight tab, and “Test Information”. Add your contact email. It won’t show up in the TestFlight iOS app until you do this crucial step. Then, click to “Testers”, and your internal testers should be there.

What’s the deal with Swift?(in my best Seinfeld voice)


1)The first big thing that comes up in almost every article I’ve read is that Swift isn’t finished, it still has important features that are actively being built and tested.

Example from the Huffpost article linked below, author Ahmed Eid states “ Currently in Swift, anything you declare in any class is automatically public and available to every other class. At one of the labs at WWDC, we asked an Apple Swift engineer if it’s possible to make a property private, (that can’t be altered from a different class), and we were told that this is indeed coming in the next few months”. (as of 6/13/14)

Programs written in Swift also cannot be released until Xcode 6 is ready, which is still in beta and won’t be ready before iOS 8 / Yosemite ships.


2) Swift can be experimented with in an interactive environment called “Playgrounds”. This tool allows the programmer to view the effects of changes or additions to code as you type, without having to run and execute code for every change.

3) The continued importance of objective- C when working with Swift:  If you want to use C/C++ libraries in Swift you will still need to talk with the libraries using OB-C. Apple made it possible for Swift and OB-C AND C++ to all coexist in the same app, so a given program could be written in 3 different languages.

4) The frameworks are written Objective-C. A programmer might have a hard time finding bugs until execution is deep in Apple’s code. If you want to understand what the debugger is telling you, you will need to understand Objective-C.


This bignerdranch article also talks about which program may be easier to learn. The author states that having a solid foundation in Objective C will make learning Swift much easier!

5)  Nitty Gritty: Technical differences of Swift

A) Type Inference: Programmer doesn’t need to annotate variables with type       information. The compiler infers it from what value is being set to the variable.

B) Generics: in which algorithms are written in terms of types to-be-specified-later that are then instantiated when needed for specific types provided asparameters.

C) Containers: In Objective-C, arrays and dictionaries can contain any type you want. But in Swift, arrays and dictionaries are typed. And they are typed through the use of Generics.

D) Mutability:. There are no “mutable” counterparts to Array and Dictionary. A programmer will use the standard let and var. Let is used to declare a variable as constant, and var is used to declare a variable as a variable. Let is like using const in C/C++/Objective-C.

E) String functionality:Swift makes dealing with strings much easier to handle. For example,  you can concatenate strings easily using “+=” and compare strings using “==” instead of the having to type out “isEqualToString:”. Strings can also be used in switch statements.

F) In an article published by Javaworld, which is linked in the sources below,  author Paul Rubens explains another big change for Swift,  Tuple’s: “ A tuple lets you group multiple elements into a single compound variable. The values in a Swift tuple can be of any type and don’t have to be the same type as each other. You can make a tuple from any permutation of types that you like: (Int, Int, Int) or (int, String) or (String,Bool) or whatever else you need. There are a number of ways to get the values in a tuple. You can access them by index number (starting with 0), for example, or you can decompose a tuple into separate constants or variables.”

G) Control Flow: The switch statement has been significantly updated in Swift and can now match against ranges, list of elements, boolean expression, enums amongst others. It doesn’t fall through by default, and is further enhanced by Swift’s flexible pattern matching.

H) Optionals: An optional type is a type that might contain a value of a type. It allows you to more easily convert between types and avoid null checks. Optionals can be chained together to protect from exceptions when calling multiple methods or properties in a chain where one call might return “nil”.


6)Apple attempts to make Swift a safer language. Programmers must include brace brackets to open and close “If” statements. This change will prevent a variety of  bugs such as theSSL “goto fail” error.  Switch statements also must include a default statement. This will make sure that something will run at the end of the statement even if none of the possibilities in the statement are satisfied.

7)  Apple’s new iOS 8 SDK will include over 4,000 new API’S. From the Apple link below, these are a few of the new and exciting API’s Swift will offer:

  • PhotoKit, so developers can tap into the power of the same robust framework as the built-in Photos app for faster performance, nondestructive edits and the ability to both read and write to the Photos library;

  • new Camera APIs, giving developers fine grain control over focus, white balance and exposure;

  • CloudKit, a complete and scaleable back-end solution helps developers eliminate the need for writing server code and maintaining servers; and

  • new App Store™ features for developers like app previews and app bundles, the new iTunes Connect with free analytics and TestFlight for beta testing pre-release apps.

  • HealthKit, combines health data to help you take better care of your health


8) Other Links:

Official apple book on Swift: Free download:

Apple Developer Tour of Swift:

5 best Swift tutorials:

A Simple Android App

I’ve had to clean up a few “first apps” and that led me to wonder- are there any good tutorials out there? This app is probably the most super simple Android app you can make. A button! That does something! But it’s a good starter- it’s bare bones, only what you need to have.

Download full final code here.

This is for SDK version 19 (KitKat). This sample app will have a button, that when clicked, does something. This works, though for any SDK 8 and up.

1. Download the Android SDK from Google.

2. After successfully installed, create a new Android App: File/New/Android Application Project.

3. Give your app a name, such as “ExampleApp”.

4. Set “Theme” to “None.”

5. Click “Next”


6. Unclick “Create Activity”

7. Click “Next”

8. Click “Next”

Screen Shot 2014-06-15 at 5.22.34 PM

9. Unclick “Create Activity”

10. Click “Finish”.


Why did we uncheck things?
Basically, with version 19, you get a lot of complicated features with a default app- such as fragments and menus- that are best explained after you make a simple app.

Clean Up Project (Remove Unnecessary Files)

Once you click Finish, Eclipse creates an app with relevant directories in your workspace.

1. In Eclipse, open AndroidManifest.xml. In this file, remove the line, under Application, “android:theme=”@style/AppTheme”” Make sure the Application still has an ending bracket, “/>”.

2. In each “values” directory, delete the “styles.xml” files.

3. In lib/ delete the “android-support-v4.jar” file.

4. At this point, go to Project/Build Project. It should build successfully, and you should have no red x’s near any of your directories.

If you do, compare your project to mine up on Github, a bare-bones template for starting an app with no activities or Java classes.

Creating an Activity

1. Right click (or Control-Click for Macs) on the project name in your Package Explorer, and select “New/Class”.


2. Enter in “MainActivity” (or whatever you want to name your first view). For the Superclass, enter “” and select “Finished”.

3. In the AndroidManifest.XML file, add an Activity element within the Application. Also, for this Activity, nest an Intent-Filter to launch the activity.

<manifest xmlns:android=""     package="com.example.exampleapp"     
    android:versionName="1.0" >

        android:targetSdkVersion="19" />

       <activity android:name="MainActivity">
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />

4. In, add the following code: the package (your full app name), the libraries we will use, and we’re inheriting and modifying (later on) the onCreate() method.

package com.example.exampleapp;

import android.os.Bundle;

public class MainActivity extends Activity {

    protected void onCreate(Bundle savedInstanceState){

Take a moment to Build Project to make sure you haven’t introduced any errors.

5. Now we’ll create the layout- the first user interface element. Select the layout directory in the Project Navigator, and right-click or Control-Click, select New/Android XML File.

6. Name the file “activity_main.xml”. In “Root Element” leave LinearLayout selected. This will create an xml file in your layout directory named “activity_main.xml”.

Save files, build project, to ensure everything is trouble-free. There should be no red x’s next to files.

7. Next, open up and in the onCreate method, add the direction to load the xml file:

    protected void onCreate(Bundle savedInstanceState){

8. Back in the XML file, let’s set the background to red, so we know it’s working properly: in LinearLayout tag, add “android:background=”#cc0000″”:

<?xml version="1.0" encoding="utf-8"?>
        android:background="#cc0000" />

Build, and make sure no errors were introduced.

9. Tether your android device to your computer. Select Project/Run, a window will pop up to select what device, select your android device, and see your app pop up with the correct color you set in the activity_main.xml file.

Adding a Button

1. In “activity_main.xml”, within the LinearLayout tags enter in the Android xml code for a button:

    android:layout_height = "wrap_content"
    android:layout_width = "match_parent"

2. Save, build, and run. A button should appear.

3. Let’s add a value for the name of the button. To do that, open values/strings.xml and add <string name="button_title">Press Me</string>

Save and build. Check for errors.

4. In activity_main.xml, for the button property, add, android:text="@string/button_title"

Save, build, and run on your device to see the text appear.

Adding Action to a Button

1. Let’s add some action once you click. In activity_main.xml, add to the button property: android:onClick="wasPressed"

2. In, let’s add a method called “wasPressed()”:

public void wasPressed(View v){
    Log.d("myexampleapp","Button was pressed.");

This will log “Button was pressed” to “LogCat” at the bottom of Eclipse, there is a little running Android robot icon, click that and view the Logs. Create a filter by clicking “+” in the left hand panel, and add for the tag, “myexampleap”. That will filter out the many messages to just the ones spawned by your app, and the ones you’ve coded with Log.d (d for debug).

Save and build, open Logcat and select your filter. Run the app. Click the button. You should see the message “Button was pressed,” each time you click it.

If tethering your device doesn’t work, go to settings/developer mode and make sure USB debugging is set to on.

If you errors that you can’t clear: go to Project/Clean. Uncheck “build automatically.” Select your project, clean, and then build again. Back step through the steps to and verify each way. Usually it’s XML errors, so keep an eye out.

4 Lists of Mobile Advertising Companies

YourAdHereMobileIn a quick quest to learn more about what options were available for mobile advertising, I came across a few links that list what companies are out there. I discovered there were more options than initially imagined.  The largest list has more than 400 companies listed.  Perhaps this will be helpful for you too!

Here’s what was discovered organized by list size:

Small – 9 Mobile Advertising Services via Tut+

Medium – The top 10 mobile advertising companies via VentureBeat

Large – Top 50 Mobile Advertising Platforms in 2013 via AppFlood

X-Large – Extensive List of Mobile Ad Network Companies (400+)  via Abhinav Gulyani

Announcing… Thinknote!


THINKNOTE, the latest app from PickAxe Mobile, is in the Apple iTunes store! Download today to make music with your mind, when coupled with the NEUROSKY MINDWAVE headset.

The NeuroSky MindWave headset reads brain activity and creates two algorithms- attention and meditation- and recognizes blinking. Thinknote translates these into a musical chorus.  With Thinknote, you can hear what it sounds like when you think of a loved one, when you’re studying for an exam,  or when you meditate.  Discover new new ways of making music with Thinknote.

Self-discovery through Wearables

IMG_0280With all of the new emerging technologies in wearable personal hardware, we are inundated with data. How to interpret it becomes the challenge. For many, we can easily interpret the results of various data points if it’s through sound. Creating a unique feedback experience leads to insights into our brain and thought patterns, as well as a composition tool, that you can download and share to Facebook or via email.

Audio feedback: a unique brainwave experience

Most, if not all of the feedback apps in the store for the MindWave visually represent data. Experiencing brainwaves as music not only helps reduce the amount of feedback while you’re monitoring your brainwaves, but also creates music and melodies all on its own. Realize how it unlocks the mind’s expression by turning data into something easily recognizable, sound.

How we chose the sounds

IMG_0288In this current release, we created the meditation sound as a vocal chorus. The attention algorithm is represented as violins and a string section. Blinks are a percussive cymbal crash sound.  We believe using escalating notes that start low in the octave scale and going higher, mirrors the way the brain waves move up and down from low points to high points.  This is determined by the value from the MindWave of intensity of brainwave, for attention, meditation or blinks. See how the colors mimic the audio, adding another layer of feedback.

Who we are

PickAxe Mobile created the popular Facebook mobile game Lyrics, an open-ended singing game, think: karaoke “Words With Friends.” Many apps later, we are helping entrepreneurs and organizations launch mobile products to get their first customers, or first funding. Contact for more information or opportunities.


How Much Does A Mobile App Cost?

Lots of Apps

This is the number one question we get from CEOs and entrepreneurs. I typed it into Google, and up popped a domain– yes, a domain- someone has made because everybody asks this question. It’s a good idea, and a good question. The wizard leads you through a myriad of choices. The app I defined in this wizard cost $23,000. Of course, it’s free because I know how to make apps, but an interesting way to lead you through the process. I’d actually estimate the cost at $8,000. How did I come up with that? Below, I will list below the ingredients to the cost of an app, and then options on how to make it (consulting, services, etc.)

Here are some apps, and what they cost:

Angry Birds $140k (Wired)
Instagram $144K – 500K (Quora)
Twitterific  $250,000 (StackOverflow)
Obama App  $50 – $150K (StackOverflow)
Average Corporate App (in my experience) $200K

(If all this seems expensive & daunting, consider doing a prototype!)

Main Cost Factors

1. The type of app

Consumer: more expensive, graphics, etc. have to be top notch, testing, wider base, more user-experience work has to go into it
Business-to-business – can be less expensive, though will probably interact with legacy backend systems.
Internal tool – much less expensive, can iterate and start off more rough than public apps.

2. Number and complexity of features

This is the largest issue, really. So, any way you can drill it down to a simple feature set will save you money. Logins, messaging, crafty algorithms, interacting with other systems and API’s, animation, large structured databases, etc.

3. The level of design

The most awesome, most beautiful app will cost more. A good-looking app is cheaper, a functional app is cheapest. If you come with iconography, logo, branding in hand, it’s cheaper. If you have a style guide already made, it is wonderfully cheap. There is still work involved making the assets work in different environments.

4. The amount of work you have done, as product manager

Here is a checklist of work you, business person, can do to make this cheaper for you:

  • Competitive research
  • Explanation of all features
  • Wireframe screens – photos of whiteboard mocks, mock-up tools, etc. are good 
  • All user cases (Are they logged in? Are they a recurring user? etc.)
  • Marketing paragraphs for store, branding, etc. done

Note: just because some code has been done by a previous consultant does not mean it’s x% done, and thus cheaper. Legacy code, especially done by a junior developer or very buggy for various reasons, can actually be more time-consuming than starting from scratch. The business and product definition work, though, is always very valuable to making a project faster/cheaper.

5. And lastly… the platform

People think this is the #1 determinant, but I’d say the above are more important. I can write in all 3- mobile web, Android and iOS, and while some are faster than the others, the factors above all contribute to the ramp-up time before coding actually starts.

Cheapest: Mobile web
Cheaper: Android
Least Cheap: iOS

But, for the success of your app, go with the platform that your future (or present) customers use. Mobile web is nice for new projects, on a limited budget, to determine product features and get customer feedback. Native is the way to go for great responsiveness and use.

Cost of Services

Individual contractor: Good developers are $100-$200/hour; Junior devs $50-$100, based on experience and skill in the language. Multiply that times duration (complexity of features).

Depending on your skill as a project manager, these can run wildly over-budget or under-budget.

Contracting Services Firms
I put service companies into three buckets:

$10K -$50K: The small fries. They make little games and/or are just starting out. You may find a diamond in the rough or a fly-by-night venture. You might end up spending more on poor-quality code, or you can luck out with a great relationship with a freelancer who wants to maintain it ongoing for free. Can go many directions, more risk, but more reward.

$50- $100K: Either part of a larger firm with other expertise, or have established themselves with more clients, apps, talks at conferences, etc. They can pick and choose more.

$100K +: They are used to building 6-month or more long, more comprehensive apps for larger firms with bigger budgets.

They will ask the questions above to determine, right away on a phone call or email, whether you can afford their services and/or your app is something they do. They will be better at communicating with you, managing their staff, and delivering solid projects. One caveat to these services, it’s not in their interest to help you define a product that is cheaper.

 “Make an App” tools on some platforms (PhoneGap, Appcelerator, Corona, etc.). These are great for making prototypes, to show investors. You may not be able to move that code to something more real later on, as some of these are written in languages that don’t port well to native code. If you do get the technical chops to build one of these, you can see above, hiring a consultant, to manage their work a little better.



Building the Kitchen Sink App


No… I got the kitchen sink too.

The impulse to build a “kitchen sink” app comes from, I believe, a few places:

  • Fear that users will be disappointed with less features
  • Requirements from other stakeholders or teammates
  • Belief that mobile is a direct corresponding medium to web; what’s on the site should be on the app
  • That users come to mobile with the same expectations as desktop or browser users
  • That time and cost estimates are the same with web as mobile
  • Unclear knowledge on how long it takes to build software (vs. websites)
  • Fundamental belief that stakeholders know better what customers want

I’ve seen, up close, two different projects that began with a large spec. They had various logical and thoughtful reasons why they needed to build out big features. Justification for each case was based – not on customer feedback or metrics – but on business cases, perceived necessity, competitive advantage and financial reasons. Customer satisfaction was important, but it wasn’t a direct “they wanted this”, more of a “we believe they want this,” and more “we want this.”

I’ve also seen, up close, small applications developed with customer feedback. A lot of time is spent on planning and testing, and development is quick, and relatively simple. Customer feedback is always the number one reason features are built. There is a lovely basic, direct knowledge that customers want something, because they basically said so. Iterating quickly, getting feedback, building what they want, it’s a cycle that – when done right- results in great software.

What really gets me is when someone asks for a kitchen sink, and points to one of these small prototypes that evolved over years, as an example of what they want out of the gate.  I start telling them the story of that app- how it had modest beginnings, the missteps, the corrections, and what they see as the the final app was not, at its core, a kitchen sink app. Instead, it was a carefully crafted- by the customers- application of what they want and needed, over time. The best justification for why to do it this way, is of course, financial.

Best Reason: Money

In the two cases I talked about above, where full-featured specs were thrown over the fence “90’s style,” the projects ran way over cost. The cases where projects launched modestly and gained traction with the user base, and product direction was largely determined by necessity on the part of the customers, were very affordable. We got into a loop of launch and test, gather feedback, communicate with engineering team. Build release, launch and test, etc. This was with a live production app, as well. Yes, there were issues, there were rollbacks. There were apologies to user bases. But since their app was getting built as they wanted it, we had a very happy base that felt listened to, and catered to. Engineering was happy- the development was always justified not by some far off goal, but by actual user cases, expressed by the users.

Another good reason: Engineering

One client approached me with an in-progress kitchen sink app. I talked to him for a while and we discussed the engineering team. I could see some flaws in organization- the senior lead didn’t have enough time and energy to devote more full time to the project, and the junior developer had time, but not expertise. The list of features was ambitious, and without a full time senior developer, I could see how decisions were being made, and time spent (billable) in the wrong directions. Spaghetti comes to mind. While he was interested in me working with his lead, it would largely be pointless as he needed to rebuild his product design with his engineering team in mind. Don’t do anything new (the project was daunting enough for a junior dev) stick to common UI objects, keep it simple. Release early and get the lead to build a good iterative testing and analytics framework – that he can do in his short time. See how you can mold the project, a modest, one-feature app, to the team you have? Another great reason to KISS, is accessible resources. Prototypes rarely require that much intense engineering. It’s the business idea that’s the secret sauce, not fancy code and algorithms. Well, unless fancy algorithms is your business idea.

When To Be Beautiful: CEOs and Perfectionism

I’ve worked with many CEOs at this point, and all of them are perfectionists. Literally, all of them. To see, use, or even publish a rough functional prototype, I’m sure is like scraping their nails down a chalkboard. So why do it? And how much should they compromise, if they compromise at all? And of course what everyone is thinking- WWSJD? (what would Steve Jobs do?)

I am not a perfectionist, I’m a finisher. I like to wrap up projects. I once took a train trip with my mother, and about 4 of her in-progress sweaters. By the end, they were all done.

For software development projects, a balance of a finisher and a perfectionist is a magical combination. While there’s tension, it’s largely productive. Here is a staged layout of releases and expectations of design perfection- the whys and wherefores to settling with less than perfection.

1. Prototypes should only communicate concept.

If you’re out to try to prove a point, or communicate an idea or basic function to an app, make sure that the number one feedback you get is about the concept. So it shouldn’t be remarkably pretty, or even super ugly, but it should communicate the concept. All design and details should point to: does it communicate what I’m testing, be it uploading a photo, chatting with coworkers, or a new way of filtering products.

Being a perfectionist may seem to make sense- I’m making sure the concept is easy and understandable. And that’s true, but it’s the nature of the feedback, and the stage your’e at in the process, that you need to watch out for.

There are two reasons not to strive for perfection at this stage: time/money, and the general goal of a prototype. The concept has a high chance of being scrapped, and all energy, time, and resources used to make it perfect will be down the drain. It is very likely things will change so much that entire flows or features will be tossed. Secondly, the team is striving for function not design, so getting design feedback is like watching a movie and saying it’s not funny, when it’s a drama.

This is the time for the CEO to give input regarding the communication of the goal and functionality. Wrong colors, wrong images, bad fonts, that all is valid in the beta/version 1 phase. Not in prototype. Login is unclear, Facebook doesn’t post, that’s all very relevant feedback in prototype phase. “This is just a copy of Instagram,” or “It should immediately launch on the map” that is all very useful functional feedback that myopic programmers may miss because they are focusing on getting it working, not through the eyes of the user, or the market.

In the software release cycle, there is a time to be pretty, and to be perfect. The prototype stage is not the time.

2. Betas should be pretty

For beta versions, you’re releasing to users, albeit power users, supportive, ready to give detailed feedback, and otherwise “invested” users. You’ve gotten feedback from several prototype concepts and decided on one app feature. You have built out, or modified, the prototype to handle real production data and smoothed out the functional kinks.

Now, this is the time to be “pretty.” To comb your hair nice and otherwise be presentable. So make sure the colors and palate in app are consistent, make sure everything lines up nicely, even margins, the flow is solid and understandable. To the CEOs reading this- work with your team and communicate that it should be “undistractedly nice-looking” that is, there should be no reason for the beta users to think about the design. There should be no logging output or awkward flows, crashes, etc. We are beyond functional, but because things will still change a lot, not ready for the time investment of perfection.

3. Version 1 should be perfect (Beautiful!)

Now you’ve integrated feedback from your beta users on flow, design, confusing spots and improved some latency issues or other production-level problems. Now, is the time to invest designer and UI/UX and front-end engineering hours into being perfect. Things are functionally not going to change until another version. For mobile developers, the front-end is not so easily distinguished from the back-end. So get your best UI programmers for mobile involved, and get their pixel-perfect eye and have them iterate quickly with UI/UX designers to determine the best most beautiful way to build this- without changing flow or functionality. Note: integrating them in the uglier versions helps them understand functionality restrictions, and helps integrate their feedback earlier in the process. The hardest part now is resisting functional feature creep and modifications, and to shunt that to Version 2.