Luc Vandal:
Let’s face it, the app gold rush is well over. It is now much harder to make it into the market and it requires more planning, financial investment and time. On top of that, competition is fierce, your app may get sherlocked (1) by Apple and become a part of the next OS release or may lose traction because a VC funded company is offering a free alternative and has near to unlimited funds for market it while they figure out how to monetize it. (2)
[…]
I have spoken with other successful developers and many told me the same: sales are generally down. They are still doing great but there are more and more competitors are also taking a slice of the same pie.
Update (2014-07-15): Chris Adamson:
That’s @jonathanpenn, as he heads off to Apple. He follows a number of top indie developers/author/speakers to head to the mothership in the last few months, including Patrick Burleson, Kevin Hoctor, and if we’ll go back a little over a year, we can throw in my former iOS SDK Development co-author Bill Dudney.
This is causing a little bit of angst among those of us who hate to see our friends decamp from our communities to California, and to suggest that maybe indie iOS development/writing/speaking isn’t tenable.
Janie Clayton-Hasz:
I don’t even know if what I want to do is feasible. Other developers that I have spoken to have seen contract work dry up because iOS has become a mature enough platform that companies are creating in house developer teams rather than hiring contractors to do piecemeal work. Additionally, it is conventional wisdom that the market for paid apps has also mostly dried up.
Matt Gemmell:
We’ve had our (latest) software Renaissance in the form of the mobile platforms and their App Stores, and I think the software biz is now starting to slide back towards consolidation and mega-corps again. It’s not a particularly great time to be an indie app developer anymore.
Small shops are closing. Three-person companies are dropping back to sole proprietorships all over the place. Products are being acquired every week, usually just for their development teams, and then discarded.
Update (2014-07-16): Matthew Smith (via David Barnard):
Our revenue has fluctuated and declined significantly over the past 2 years. We have tried everything we could think of to reverse that declining revenue trend, and nothing has worked. We have had a blast making high quality educational kids apps, but at some point you have to take a step back and say ‘Is this sustainable?’.
Apple Business iOS iOS App Mac Mac App MoneyWell Screens
Milen Dzhumerov:
Unfortunately, as it regularly happens on OS X, the need for maintaining backwards compatibility has lead to important differences and unexpected behaviour in the exact same API when compared to iOS.
[…]
The situation is slightly different on OS X – once Auto Layout is enabled, AppKit insists that the positions of all views be determined by the constraint system, even for views which are not referenced by any constraints. AppKit will flag any such layout as ambiguous, even though it is not in practice - all views part of the constraint system have well-defined positions. I consider this to be a bug, as I cannot see a reason why such hierarchies need to be flagged as ambiguous (in fact, it works just fine on iOS). The good news is that even though the layout is incorrectly deemed ambiguous, everything seems to be working fine.
[…]
While the difference seems small, it has a very important implication. The reason why -setFrame: is used on OS X is due to backwards compatibility, as a -center property does not (necessarily!) exist at the NSView level (it exists only when layer-based). But due to the introduction of Core Animation in a backwards compatible way, it means that when we have a layer-based view tree, the positions are ultimately stored by the CALayers. And crucially, calling -setFrame: on a CALayer is semantically different to calling -setBounds:, -setPosition: and -setAnchorPoint:.
CALayers do not really have a frame property, as frame is a function of bounds.size, anchorPoint, position and transform. So when Auto Layout sets the frame of the layer, it also resets the transform to the identity. This is an extremely important behavioural difference that needs repeating: Auto Layout on OS X resets -transform of the the auto laid-out CALayers, essentially turning it into a read-only constant. Obviously, this does not happen on iOS as -setFrame: is not used. This behaviour prevents us from using the transform property – e.g., we might want to scale or rotate views but Auto Layout will be overwriting the changes we apply.
Auto Layout Cocoa iOS Mac Programming
Jonathon Mah:
The first call to [super layoutSubviews] will evaluate the constraints on the label (since it’s a direct subview) and change its frame accordingly.
At this point the width is useful, but the height is not; the height was set using the label’s intrinsic content size, which in turn relied on a preferred max layout width value that is now stale.
Now we know the actual width of the label, we set that as its max layout width.
Internally, this causes the label to invalidate its intrinsic content size; when it’s next queried, it will have the accurate height for its current width.
With all layout information in place, we call [super layoutSubviews] again.
Auto Layout Cocoa iOS Mac Programming
