430 karma · joined July 29, 2009
Created Just Landed (iOS) - a better way to pick people up from the airport http://getjustlanded.com
Created Patchmania (iOS) - an adorable puzzle game about bunny revenge http://getpatchmania.com
Created SimplyListed (iOS) - a better way to sell your used stuff http://www.simplylisted.com
First product lead at Dropbox. Early employee at Yammer. Once was a serf for EA Games.
Montclair, NJ https://jongrall.com
You might be surprised to know that many customers on the App Store, and even some members of the press, seem to think that apps being featured by Apple have been bought by the company. I would get emails like: "how have things changed for you since Apple bought your app?"
If people knew how bad the app economy has become, there'd be far fewer app developers than there actually are, and the device makers would have a serious PR problem on their hands.
In the end though, I do believe that the short-term thinking I alluded to in my post will soon come home to roost. I do hope that Apple and Google course-correct before we end up in a situation where indie apps are a distant memory. It's in their long-term interest to keep the App Store diverse and the app economy healthy.
The proliferation of half-decent free flight trackers (albeit without the unique airport pickup focus), the other systemic problems mentioned in my post, and the increasingly common cannibalization of utility apps by Apple's iOS itself, led me to the conclusion that such an endeavor was likely doomed to fail.
Just because you can find passionate users doesn't mean you've found a good business, and that was the case here.
Honestly, if you're reacting to the video showing iOS 6 I think you're probably focusing on the wrong thing.
Honestly, because we're an app company rather than an e-commerce or SaaS company, a lot of the effort we put into these pages is largely for the benefit of the press (who often research apps on desktop). The vast majority of end users discover our apps through the App Stores themselves, so we put even more effort into our icon, screenshots, app preview, description, keywords etc.
As for conversion rates, sadly Apple hasn't opened up any analytics to developers for their actual App Store product pages (even though they announced they would a year ago at WWDC), so what users are doing when browsing the actual stores is largely a black box - we have no idea how many people view our app store previews or screenshots etc. or even where they came from (many deep-linking schemes we've looked at are pretty brittle or don't work at all).
Conversion rates on the website landing pages are pretty good - there's not much else to do on those pages than download the app, and chances are you came there with that goal.
Having said that, a month to live is still a month to live. Talk about the situation with your team members and advisors and try to figure out whether or not it's salvageable. Perhaps, after making some difficult choices, there's a way that you can still continue. There have been moments in my own startup experience where things seemed really bleak and hopeless, and it seemed time to give up, but in the end we actually got past it. Another friend of mine had a situation where he literally had no money left in the bank and took the company to Vegas on credit card (I don't advise this!), when someone threw him a $200k life preserver at the 11th hour.
I guess the question you really have to ask yourself is whether you still believe in what you're doing. If the answer is no, then I think your involvement with the company has to end, which may or may not be fatal for the startup overall. I feel for you OP - my own startup failed 18 months ago and it's no fun. However, you'll get through it and I hope you decide to try again.
However, there are some glaring warts that weren't discussed. Most notable among the goofs is the new "Control Center" feature. What's odd is that Apple seems particularly proud of it judging by how frequently it appears in their iOS 7 marketing materials. To be clear, I think that the idea of giving quick access to frequently used controls is a good one. However the current visual design execution of this idea is abysmal.
IMHO, the current design of iOS 7 Control Center is a jumbled mess that doesn't seem consistent with the rest of the new design. It violates a bunch of the new design conventions, and conceptually represents a grab-bag of misfit controls that have little reason to be together on the screen at the same time.
The controls shown in Control Center don't use the new convention of tinting to a bright color to indicate interactivity, but instead opt for inverting between light and dark to indicate on/off. Additionally, some of the buttons have borders, while others don't. Some are circles, some are rounded rectangles, others are floating in whitespace. Some less important controls (AirDrop) are big, other more important ones (WiFi) are small, and they're all stacked on top of each other in a big jumbled mess.
Here's how I propose Apple improve the design of iOS 7's Control Center:
- Adopt a consistent control element design: no borders, color hinting etc.
- Remove the bottom row of app shortcuts. Except for the flashlight these are not controls, they're links. - Remove AirDrop and Airplay. Not controls either.
- Refine that ugly down arrow on the top of the pane. It's too chunky and is encroaching on the icons below.
- Increase the opacity on the panel to improve readability.
Paper does work well for this, and you're free to not like Balsamiq.
Btw, for rapidly prototyping iOS apps I highly recommend Balsamiq - it's amazing what you can do with that tool :)
I remember loving IB when I was just starting out with iOS. If you're building a quick throwaway app using stock UI components, it's great. However, as your app grows in complexity, and the needs for UI customization increase, IB quickly becomes a crutch and a source of hard-to-find bugs.
The nail in the coffin for me was realizing that IB would frequently get out of sync with my code if I renamed anything or moved code around. I found myself frustrated clicking through menus to hunt down incorrectly set IB outlets, fix references to nonexistent classes and methods that had been changed, and rewire event targets that had gotten out of sync with my code. There's also some UI customization that just isn't possible with IB, for example much of the stuff that the UIAppearance APIs now allow isn't customizable within IB, as well as any time you make a totally custom UI widget (IB doesn't really know what to do with it, and if memory serves me just shows a blank rectangle). Trying to add additional customization to IB user interfaces (beyond what IB can do) generally involves tagging them in IB, then retrieving them by tag in code, and then making the change. Convoluted and high maintenance IMHO.
When you add to this that changes to .xib files can't be easily merged, that it's generally pretty useless to diff them (the format is complex), and the fact that you have to look at both the .xib and your code to piece together the end-to-end functionality, it was pretty clear that dumping IB was going to be a big win for me. Turns out, it was.
I now override the -(void)loadView methods of all my UIViewControllers, and create and position all of my custom UI for each controller in there. I never have to worry about what IB will or will not let me do. Additionally, in the case of customized UI elements, I either create subclasses of UIKit classes (often subclassing UIView or UIControl), or categories of existing classes if the change to their functionality is small. Doing things this way also makes it much easier in the rare case that I need to do custom drawing within -(void)drawRect. I suppose what makes this a bit easier for me is that I have no problem visualizing the UI I've written in code before I actually see it. Other people may miss seeing their UI in IB and being able to visually edit it. I suppose I got over that pretty quickly.
If you're still not convinced, consider that by coding your UI by hand you'll also have a lot more control over memory usage since you control what gets created and when, you can share resources between elements more easily (colors, images, fonts etc.), and also avoid the performance hit of your app parsing .xib files.
But what does hand-coding your UI do to code length, you might say? In my experience it adds about 25% to the length of your UIViewControllers. Perhaps a small price to pay for all these benefits? For me it was the right tradeoff. Try it - I suspect you'll come away feeling empowered and understanding a lot better how UIKit works.