My development falls into the giant right circle and I never considered developing for the Mac OSX until after I created my first iOS game this month and learned of the Mac App Store opening in 3 months. Now it's as easy as reexporting higher resolution art from Illustrator and a few UIKit changes and I can redeploy my iOS game for Mac OSX and find myself in front of another large app hungry audience that will happily open their wallets.
I'll be one of the first in line to get on the Mac App Store when I've never before developed or sold software since this month. It is making is so darn easy to have a chance.
You make it sound like porting an app from IOS to OSX is easy. Maybe you could write up a blog post or something for ignorants like me who would be interested in doing the same. Thanks for any additional details.
If Apple ports UIKit to Lion, the API side of things could be very easy. The big challenge here is in interaction design.
Some games might make the transition relatively easily. A game that relies mostly on single points of touch has a somewhat decent analog with the mouse, but only if it relies on certain patterns of finger movement. A game that, for instance, involves alternating taps on opposite sides of the screen, would translate badly—it's nowhere near as easy to leap that distance precisely with a mouse as it is with your fingers. Can you imagine playing the iPhone classic Dactyl with a mouse?
That kind of difference is present all over in touch-based applications, in differing amounts. It's up to the developer to find what transitions well and what doesn't, but in most cases it won't be a trivial task.
Touchpads are not 1 to 1 though, like wacom tablets or touch screens, you still have to "move" the mouse, you can't just touch where you want it to go.
OK, so I'm totally ignorant of workings of trackpad (or its potential to work in ways additional to its current use), but might it not be possible for Apple to add the capability (via software) to enable tapping on left/right edge of track pad to have trigger events that are triggered by touch to left/right side of an iPhone/iPad screen?
I have actually searched for alernatve divers for my touchpad (on a pc) to do this, with no luck. I am sure it's possible though, the only limiting factrs would be the accuracy of the touchpad, and users unfamiliar with the new mode.
While Apple hasn't announced anything yet, I have to think that a lot of iOS APIs are going to show up in Lion to make it easier because, you're right, it's very non-trivial now. I mean, I'd rather port a UIKit app to AppKit than a Windows Forms app. But there are a lot more differences than there have to be.
While Apple hasn't announced anything yet, I have to think that a lot of iOS APIs are going to show up in Lion to make it easier…
Prepare to be disappointed. Technology stacks aside, if the interaction models between desktop apps and multi-touch interfaces were in any way relatable, UIKit wouldn't have been invented.
If you want to write a Mac app for the new store, you'll be using AppKit.
For those not familiar with Cocos2d iPhone, it is a fantastic open source 2d game framework. The 'mac support' in Cocos2d iPhone is still experimental, and missing a few features :
The roadmap indicates mac support should be ready this release cycle (0.95), but it probably won't stabilize until 0.96. Once finished, porting games written with Cocos2d between iOS and Mac should be trivial, allowing for differences in input.
If anyone is interested in learning more about Cocos2d iPhone, I've started a tutorial series for people with little or no programming experience:
I had messaged you on the Cocos2d board I think. I started working through your original tutorials but decided to wait until you redid them. Glad to see they're available now - I'll be starting to work through them this weekend!
They're available, but not finished. I've posted the first four courses, which should be more than enough to get started. The next two courses are written, and I'm (hopefully) going to have the in good shape to post next week.
I'm surprised that JWZ (and, seemingly, several of the commenters) was expecting a full OpenGL stack on a mobile phone, and seemingly wasn't aware of the differences between OpenGL and OpenGL ES, particularly with respect to the absence of the long-since-deprecated-in-regular-OpenGL Immediate Mode.
It sometimes seems as though, as a consequence of all the strides made in bringing more serious OS support, better languages and much more coherent UI work to mobile phones in the last few years, many programmers have lost sight of the fact that these are still relatively low-powered embedded devices.
I think there is something missing from the analysis of iOS applications as entertainment. Not only can I show you my new Vuvuzela app while we're sitting in a bar, I can show it to the waitress, your girlfriend, and the guy sitting next to me. iOS apps are entertaining because they are social.
A macApp is less sharable than an emailed website link. Besides my dog who am I going annoy with my Vuvuzela? (so to speak).
I suspect that macApps will sell based on utility rather than entertainment and that the removal of flash and java are expected to generate much of the initial need.
You make a good point about the social-in-the-bar aspect of iOS apps, but I think you're off the mark about gaming.
This is an area where the Mac has been weak for more than a decade. Imagine an environment that allows you to purchase a multiplayer networked version of Civilization: Revolutions (or Quake or Plants vs Zombies or a dungeon crawler version of Dragon Age) for $20 and you can play it while sitting at your desk, on the couch with your iPad or out in the world on your phone.
Given the popularity of cheap apps and casual gaming, I expect the App Store turns into a Jobsian version of Steam.
You may be right, but there are some hurdles. Networked games on individual devices don't replicate the social experience of the living room with a console, nachos, Madden and some buds. Sitting at a computer is solipsistic.
An issue with the iPad and iPhone for serious gaming is that unlike a wii controller, neither is replaceable for $25 after an over enthusiastic gaming session (durability in general is also an issue).
From a business standpoint, I'm not sure how well games fit into Apple's strategy. The market for sophisticated games is mature and growth would mostly come from capturing increasing market share rather than an expanding market and small games are easily delivered to the desktop via the web. The life cycle of a game is also much longer than a movie.
I'd say this assessment is largely spot-on. By introducing the App Store, Apple could channel the large community of developers churning out commodity software for iOS towards the Mac. Now they just need to make porting from iOS to MacOS X really simple, and the ecosystem will flourish.
One addendum, though: Existing applications won't benefit from the App Store, yes. Existing Mac developers, though, probably will. If you know Cocoa forwards and backwards, then making little (store-exclusive!) apps isn't challenging, but potentially lucrative.
Yup, brilliant (although unsurprising) move on Apple's part. By bringing iOS and OS X together (from a developer standpoint), they're able to seed iOS with Mac developers and Mac OS with iOS developers, and attract more folks overall to both platforms.
This is exactly what I was thinking while watching the Lion demo especially with the full screen applications. AppStore or no AppStore the average Mac user isn't going to impulse buy an expensive, complex, multi-function application without an obvious purpose communicated through 2 or 3 screenshots. The key to the Mac AppStore is going to be de-constructing these multi-function applications into smaller task focused tools with re-invented UIs (iOS stylized) at lower prices.
While I think Marco probably has it right long-term, I think he's actually pretty wrong in the short-term. The difficulty of porting an iOS app (or even writing a Mac app from scratch, given that a developer only has iOS experience) and the nature of the device (mobile is clearly a growing market--is the same true for the desktop?) means that I think we'll see a lot more trepidation in entering the Mac App Store.
Traditional Mac developers (Panic, Omni, etc.) will obviously move their apps onto the store, but I don't think we'll see a whole lot of new entries--most iOS apps don't neatly transition onto the desktop, besides some games. I know my couple iOS applications don't have an obvious Mac version, just as my Mac applications didn't have an obvious iOS version. If the Mac App Store is to reach anywhere near the popularity of the iOS App Store, it's going to take a long time for companies to decide that the desktop is even worth it.
If Panic and Omni find that all they have done is reduce their revenue by 30% then they won't stay long. I'm not at all sure the extra volume will be enough to offset the cost, especially if the store becomes full. It is going to be interesting.
Your ignoring the other things you get from the app store. You need to compare the 30% cut apple takes off the top to the possible increased volume of sales, the money saved from not having to host the app yourself or having to run your own payment system. Apple is not just taking 30% off the top to just to be greedy, it is more of a payment for the service they are providing.
If you have anywhere near a reasonable volume your payment processing shouldn't cost more than a few percent, nowhere near 30%.
Hosting costs aren't going to go away, you will still need a web site, you might be able to save a little download bandwidth but that hardly breaks the bank nowadays.
I don't think Apple are being greedy, I'm sure that is a reasonable reflection of their costs, I just wonder how it will add up for developers like Panic or Omnigroup. If their volumes double then it makes sense, if they only increase slightly or not at all then it doesn't.
I think that's entirely the wrong way of looking at it. This removes payment processing, download costs and (critically) installation support and serial number issues hassles.
But that isn't really what you're paying Apple for. You're paying them for the creation of a new market that may (or may not) be better for you. Discovery (formerly marketing) is going to largely be their thing. Customer education will become standardized. Trust - they will teach people that apps are safe and hassle free to install & uninstall. They will teach consumers what an app is.
This will probably amount to far more then an increase/decrease in sales. It will determine which apps succeed and fail. These will be different from the winners and losers in the existing, "natural" market. It will determine aggregate demand for apps. This will also be different. It will affect consumers' expectation for what an app should be. For example, I think that learning curves will need to be reduced. The concept of learning software will be reduced.
A lot of existing software (the big names: MS Office, Adobe CS, etc come to mind immediately) probably won't fit into the app mold comfortably. Developers will have strong incentive to create apps that do. It will be interesting how much software can be "apps."
The app store only increases your sales by any significant amount if you get featured by apple or you break into a top 100 list. Now a days, to reach the top lists and to show up on apples radar, you need some sort of external marketing and exert a downward pressure on your prices. If your going to do external marketing you might as well try selling through a more profitable venue.
Will there be any good ways to “crossgrade” buyers from the retail edition of an app to the App Store edition without making them pay again in full? (My guess: No.)
You can gift someone an album on the iTunes Store. When you buy a DVD the DVD can "gift" you the iTunes version of the movie (The Dark Knight did this, though it just copied over from the disk). Why can't a software company gift someone an app on the Mac App Store when they buy the app elsewhere?
Because there's no existing way to handle that. Traditional "gifting" costs the full purchase price of the product, and the "promo codes" developers have to give out for free copies are extremely limited--only 50 codes are given out per upgrade submitted to the store (this is for iOS, I assume the same is true for the Mac).
EDIT: What I don't understand is why there's a need to do so anyway. If I recall correctly, there's no such thing for Steam, and game developers have long sold applications both in retail and via Steam with no problem. Supporting two separate applications (one with the traditional purchase and one via the App Store) shouldn't be too difficult, especially if the developer switches over to App Store-exclusive when it hits. He'll simply have to continue to perform upgrades/support however they were before, but will be able to ditch their old payment processing entirely.
Most of the games on Steam are developed and maintained by relatively large teams. Compare to most iOS developers and my guess is the teams are much, much smaller. So for the Mac, I'm guessing it would be non-trivial to be supporting two SKUs, cross grading, upgrading, etc with such smaller teams of people.
The mac app store is the end of an era. For a while the mac was the most user-centered AND developer-centered platform that existed. When I bought my first mac apple was actively recruiting developers by having free conferences around the US.
Apple has decided to go more in the user-centered direction then the developer-centered direction. This is definitely the right move for them. However it makes me a little sad, its the end of an error. Now I see linux as the developer centered OS with OS X as the most user-centered OS. Its a hard call to make.
Mostly I think I am harboring some resentment. "Back in my day we had to write our own licensing code, host a web payment code, and host autoupdates. All the kids these days do is launch the darn app." I think I almost believe its not fair.
I guess at the age of 24, I am running into one of the first big changes that I have to accept if I want to stay relevant. I knew this market changed quick, I just always assumed it would be in the way that I wanted it to change.
In what way is the presence of a Mac App Store making the Mac less developer-friendly?
If anything, the creation of yet another possible revenue channel only makes the OS more friendly to me, not less.
"Back in my day, we had to roll our own blitter if we wanted to do anything serious" could also be said, but that doesn't mean modern graphics libraries and hardware are less developer friendly. Eliminating the need to do repetitive grunt-work is always a good thing.
An App Store isn't that great for developers (in the "developers being free to do whatever they want" sense of "good for developers") when it's the only option available.
That is not the case with the Mac App Store. If you don't find any benefits in the tradeoffs that particular option provides, don't pursue it. Write your "own licensing code, host a web payment code, and host autoupdates" like the "good old days", if that's what floats your boat. But it's still better to have another revenue option at your disposal than to not, even if you don't choose to use it.
>An App Store isn't that great for developers ... when it's the only option available. That is not the case with the Mac App Store.
I keep hearing this, but I've yet to be convinced.
Over the last 5-10 years Apple has pushed developers more and more aggressively. They put giant efforts into things like Classic and Rosetta, only to strip them from the OS entirely a few years later. They repeatedly trumpeted the full equivalence of Carbon and Java to Cocoa, and now it's infeasible to use either as the basis for any full-featured application. They developed all kinds of new APIs for QuickTime in 10.5, and then in 10.6 introduced "QuickTime X" as the only 64-bit native solution, effectively deprecating everything else. And most recently there's this unusual attack on the Flash plugin of all things. It's as if they now revel in actively destroying backwards-compatibility.
All of these decisions had the effect of reducing Apple's support and maintenance overhead while strengthening their control over the direction of their platform.
I would be surprised if Apple's very clearly demonstrated zeal for taking control and eliminating developer options did not extend to the new Mac App store.
Seems to me that putting giant efforts into things like Classic and Rosetta prolonged the ability for developers to move over before dropping legacy support. The other options would be:
a) support the legacy systems forever.
b) don't support them at all.
Option A leads to a Windows-esque environment where support for older platforms actively holds back development and innovation for newer ones. Option B kills everyone's existing apps. Neither of those sounds like a very developer-friendly or even user-friendly option.
Frankly, the fact that they built those at all shows that they're willing to go the extra mile to make sure that their developers have the heads up to upgrade their applications before breaking them entirely.
Developers are mostly irrelevant in this calculus to Apple: it's what the user sees that matters. They put out Classic and Rosetta not to help developers — they were with both very clear: the train is pulling out of the station, you'd better get on board with the new thing immediately or you're dead — but to help users have something to run on the new systems. Get users buying new systems, developers will follow... especially when essentially forced to.
It seems to me that you've started with a conclusion and found facts that fit your thesis. That's the wrong way to go about reasoning.
The known facts about the Mac App Store are that it is only going to be an additional way to obtain software. It doesn't make sense to condemn it as "Bad For Developers" based on groundless speculation and presumed irrationality on Apple's part.
>It seems to me that you've started with a conclusion and found facts that fit your thesis. That's the wrong way to go about reasoning.
So let's look at it logically then. In nearly every example I gave, did or did Apple not make a promise to developers which it then broke later, costing those developers time and revenue?
And did or did Apple not recently make a promise to developers regarding the availability of an existing, long-standing technological alternative, that being direct downloads of application binaries?
Would a reasonable person extrapolate from those past observations that Apple would behave in a similar manner when circumstances similar to those that I mentioned arose?
If not, then either you don't believe that people's future actions have anything to do with their past actions, or you disagree with a series of easily verifiable facts.
there is a cost to maintaining features - ten years ago making java a first class desktop citizen was a good thing. today circumstances have changed and it's not worth the effort. so you could say that they have broken a promise - but do you expect that promise to be for evermore? or for as long as is reasonable (for some definition of reasonable)?
apple has always been that way, making life harder for developers if it suits what they perceive the consumer's needs to be.
> All of these decisions had the effect of reducing Apple's support and maintenance overhead while strengthening their control over the direction of their platform.
Yup, plus the effect of improving user experience.
The most developer-friendly thing a platform vendor can do is attract users. Apple's done that in spades.
I would argue that bringing a massive amount of new customers to their developers is actually rather developer-friendly. Maybe not "programmer friendly", as Linux is, but how many developers do you see making a living off Linux applications?
I'll be one of the first in line to get on the Mac App Store when I've never before developed or sold software since this month. It is making is so darn easy to have a chance.