Tuesday, October 6, 2009

Sue Me, I Think Developers Should Care

James Higgs has a different take on MonoTouch and Flash for iPhone. You should read it. It's good to see other points of view.

That being said, I can't say that I agree with most of it. Indeed, I feel like James is missing the point and misrepresenting the point of view of well-respected members of the Objective-C community by cherrypicking individual tweets. The fact is, I agree with both tweets referenced in his blog post, even though they come off as a little crass and even elitist without context and given that the authors had only 140 characters to make a point.

To highlight my main difference with James' opinion, let me respond to his concluding paragraph that he seems to think no reasonable person could have a problem with, and tell you my problem with it:
It boils down to this: if MonoTouch and Adobe’s Applications for iPhone platform are no good, they will die. Developers who use them will sell fewer apps in the App Store. Objective-C developers will carry on developing apps in their preferred style and creating apps that sell well. But if the rival techniques are sound, everyone gets to write great iPhone apps, and the result is happy users, and an even wider adoption of the iPhone platform.
Here's the key point missed. It doesn't boil down to that. If MonoTouch and Flash for iPhone are no good, they won't die for a reason James himself pointed out earlier in the same posting: the users don't know or care how the application was created. If MonoTouch and Flash applications are slow and crash or use gobs of memory or break under future versions of the iPhone OS, the end users aren't going to take away a negative impression of Adobe or Novell, they're going to think "Apple Sucks". They're going to blame the iPhone. It will affect the users' opinion of the individual developer, sure, but first and foremost it's going to affect the users' opinions of the iPhone as a platform.

I'm pretty sure Apple will have a problem with that. If one app sucks, it's no big deal. If there are hundreds or thousands of apps that all break or perform poorly, that's going to impact the overall perception of the iPhone.

I, personally, have a problem with a developer who feels entitled to be able to develop for a platform without investing the time to learn the language or frameworks that platform was built around. Languages affect design. Objective-C has greatly affected the design of the iPhone application frameworks and, indirectly, the experience of iPhone users. If you can't be bothered to learn that, to understand the iPhone experience completely, that tells me that you just want a piece of the pie. You see something that's been phenomenally successful, and you want to be able to take advantage of Apple's success to make some fast money, but you're not willing to understand at even a superficial level the engineering that underlies that success.

This is vitally important on an embedded device. On a desktop computer, we can tolerate Flash because we have crazy fast processors, gobs of physical RAM, and full virtual memory. On the iPhone, the processors speeds are about ten years behind the desktop, we have a fraction of the RAM, and volatile memory won't get paged out to swap, so memory use and processor use are vitally important. Yet I should be "okay" with someone who wants to develop for the platform and is either ignorant or cavalier about these things? I don't think so.

A few paragraphs earlier, James says
Like me, many developers will welcome the chance to learn a new language and a new platform But many will just want to write an app and get it into the hands of their users as quickly as they can. (emphasis mine)
Exactly. That's exactly what I have a problem with. Getting an app into a users hands as quickly as possible is not a virtue. Getting an app to the user when it's done, and good, and well-tested, and performing well is. I don't want this mentality. I want developers like Snappy Touch, who obsess over the user experience. I want developers like Imangi, Flipside 5, Tim Haines, and the countless others who cared enough to dive in and learn the platform, learn the language and tools, and deliver great user experiences on the iPhone despite having to learn to do it. I want developers who care. Developers who care, care enough to use the right tools and invest time learning about their platform and about the users of that platform.

Part of the iPhone's success is exactly because there is an obstacle to entry for developers. It's not insurmountable, in fact it's pretty darn low, but it has tended to keep out the worst of the opportunists and hammer developers, and that's been a good thing. It's not a perfect environment, but it is pretty awesome, and it's a darn sight better than it would be if flooded with people who can't be bothered to learn a bit about the platform that they want to milk for all it's worth.

Here's another thought. Even with just Xcode and Objective-C available for building iPhone apps, the app review team at Apple is completely swamped and overrun and has a very difficult job. Do you think flooding the app store with iPhone ports of every crap Flash game in existence is going to help that situation? Hell no. It's going to make the situation so much worse. Now, try and tell me with a straight face that that isn't going to happen the second Flash 5 is released to the public. Of course it is. Every Flash developer is going to raid his or her portfolio for stuff they can quickly throw up on the App Store to try and make a quick buck.

Yeah, gosh, how could anybody not want that? That will make things so much better for iPhone users.

I don't know what Apple's going to do, but if it were me, I would let Adobe know, in no uncertain terms, that Flash apps are not welcome on the App Store and that Flash developers are more than welcome to come learn Objective-C and Cocoa Touch. If I were Apple, I'd be pretty darn annoyed at Adobe's insistence and willingness to resort to borderline unethical behavior to steal a piece of the iPhone and App Store pie, and I would take steps to protect the quality of the user experience on the iPhone, even drastic steps if necessary.

But, I'm not Apple, so only time will tell.



32 comments:

sdfisher75 said...

Exactly right, Jeff.

Jonathan Pryor said...

If I were Apple, I'd be pretty darn annoyed at Adobe's insistence and willingness to resort to borderline unethical behavior to steal a piece of the iPhone and App Store pie

Huh?

Where, exactly, is the theft occurring? You still need an iPhone/iPod Touch (ka-ching for Apple), you still need to go through the App Store (ka-ching at 30% of app's cost for Apple), and you still need an Apple Developer Certificate to deploy to the device for testing (ka-ching at $99/year for Apple).

Where exactly is Adobe stealing from Apple? It's certainly not in providing an alternative to the free Xcode IDE (no profit in free products).

The one plausible place for "theft" is if a bunch of crap, crashy apps enter the App Store and give the platform a bad rap. This currently seems highly unlikely given the App Store review policies, which will serve to keep the highly crash-worthy & crappy products out of the App Store in the first place. (Plus it hasn't stopped crashing apps from entering the app store already -- TweetDeck regularly crashes on me -- and you can't blame Adobe for pre-existing apps.)

bunnyhero said...

it's the app store review overload that you point out that concerns me the most. it's already evident that the app store simply doesn't scale with the number of developers and apps that exist now. it's not just the review times, either. discoverability also suffers.

if the software ecology of the iphone was completely open, with different places to find and sell apps, then flash cs5 for iphone would not concern me. but since all of these apps go through a single bottleneck, i do wonder a little for the future of this fledgling iphone app industry.

Jeff LaMarche said...

Jonathan Pryor:

"Theft" was used in a metaphorical sense, referring to the iPhone market as "pie". I wasn't alleging that Adobe was literally stealing. I said they engaged in borderline unethical practices which, I think, is generous to Adobe.

The fact is, Apple's license agreement lays out certain terms. Adobe has, for nearly two years since they first announced they were going to bring Flash to iPhone come hell or high water, they've worked hard to force Flash onto the iPhone against Apple's wishes and against the explicit terms of the license agreement.

There's absolutely no way they could have accomplished the feat of letting Flash generate iPhone apps without downloading Apple's SDK, agreeing to the SDK agreement, and then violating those terms by reverse engineering parts of the SDK and/or creating derivative works.

A company that is that cavalier about contractual obligations does not deserve any respect.

higgis said...

Hi Jeff. Thanks for the reply. I was in no way trying to misrepresent the view of well-respected members of the community. In fact I went out of my way to show how much I *did* respect them and the community. I respect Pilky's work enough that I've forked over hard-earned cash for some of his software. I have ultimate respect for Chris because he's clearly a much better developer than I could ever hope to be.

Onto your specific points. Here's how Flash or MonoTouch will die if the apps are crap compared with the ones developed with the native tools:

1/ Devs publish apps that are rubbish
2/ Apps get poor feedback
3/ Devs blog about how it's impossible to develop decent iPhone apps without the native tools
4/ The end

I'm not clear on your argument about how Flash and MonoTouch would flood the app store with crap. Haven't you been complaining about this anyway? You can, last time I looked, create really poor apps using the native tools. I can't see how quality is an argument in that case.

Also, there are already people who want to make a fast buck. And here's the thing I've never understood about this argument. If people who want to make a fast buck are not delivering things that people want, then people won't buy the apps and the people won't make a fast buck and will go away. The only other option here is that people are making a fast buck on things you personally don't like, and that means you think that they shouldn't be allowed on the platform. But that goes against everything you've said about how the approval process. So, bring on the fart apps, I say.

As far as Apple breaking these apps with future updates goes, they're already doing that with apps built entirely with native tools, and on OS X too. I now of many people who had their entire phone bricked by OS 3.1. It's something you have to get used to as a Mac user (see Merlin Mann's rant on this for more). Also: apps developed with MonoTouch or Flash go through the same exact app submission process that other apps do, which includes Apple quality control. Either that quality control isn't good enough, or there isn't a problem that relates to which tools were used. (And, according to DF, there are already seven live apps in the store built using Flash.)

One of the tenets of agile that I like the most is the idea that *working software* is the most valuable thing to users. Getting it in the hands of users - bug free and a great experience included - is the goal. As El Jobso is reputed to have said "Real artists ship". As I acknowledged in the post, Mac software generally is of a far higher standard that on the PC. But that isn't because of the tools: it's because of the ethos of the platform and the attitude of the user base.

I think my biggest problem with all of this is that I'll bet that none of the people slagging these new tools off has actually tried using them. They write them off in principle, and I think developers of the stature and ability of people like Miguel deserve more respect than that. Mac developers *can* come across as elitist - and I like a good bit of elitism myself - and part of that is communicated through an attitude that people need to have the road to Damascus moment with Apple's tools.

I'll say it again: if the app is good enough, who cares what compiler produced the binary?

Cheers,
James

Jeff LaMarche said...

James:

I guess there's just a few things that I see playing out differently. If, hypothetically speaking, Flash apps are crap, most users aren't going to read the developer's blog, Adobe is going to spend money making it look like it's not their fault, and entrenched Adobe shops are going to be just as resistant to using other tools as they already are.

The end result will be a degraded experience.

And even if Flash rocks, there's still going to open the floodgates, meaning longer review times, more crappy stuff getting on the App store, etc.

As far as Apple breaking these apps with future updates goes, they're already doing that with apps built entirely with native tools, and on OS X too.

Yes, of course, OS updates sometimes impact individual software packages. But now what happens if an upgrade affects the mechanisms Flash uses. Instead of isolated problems with a handful of apps, it'll be a problem with hundreds or thousands of apps, and that will reflect badly on the platform because, as you state, users don't care what tool was used.

The idea that any tool that works is great in theory. The problem is, consumers don't think of their phones as computers, they think of them as phones, and when they break or don't work, they blame the company that made them.

MonoTouch and Flash 5 increase the volume of apps and the layers of abstraction where bugs can exist. Instead of just your own bugs and Apples, you also have to worry about Adobes or Novell's. More possible points of failure, and Apple doesn't have the bandwidth to be everybody's QA department. Sure, they reject apps that crash, but they don't do full-on QA and crappy stuff inevitably does get on the App Store. I don't see how that in any way helps the argument that the floodgates should be opened up. To me, it seems to say the opposite: limit the tools used to those Apple used to write the darn thing, reduce and the number of layers where bugs can exist and reduce the number of new apps coming into the App store.

I don't see any incentive for Apple to allow this, to be honest.

And, of course, there are people who want to make a fast buck. I didn't say otherwise, though I said having at least minimal obstacles to entry helps some. I can tell you that I get almost daily e-mails from people who want in but don't want to learn to program. The usually generously offer me half the profit if I'll write the app for them.

Because the current situation isn't perfect shouldn't be justification for letting it become worse.

I think my biggest problem with all of this is that I'll bet that none of the people slagging these new tools off has actually tried using them.

I don't think you necessarily need to use the tools to have an opinion, as long as you understand the engineering that went into them (and I guarantee you Chris does). As I've stated before, it's not the developer experience that matters in this equation, it's the end-result. Flash for iPhone creates bloated, slow apps. It doesn't matter if the IDE is awesome. That's not the issue at all.

In both Mono and Flash, they are adding a level of complexity to an already complex environment, and they are adding things that are not necessarily that similar to or compatible with what's already there. I think C# is great for writing .Net apps. That doesn't mean it's necessarily the right choice for writing iPhone apps.

I respect Miguel and the Flash team for the engineering feats they've accomplished. But I still think they are both misguided attempts. The fact that you've accomplished something difficult, doesn't mean you've necessarily accomplished something good.

higgis said...

Hi Jeff,

Quote: "Flash for iPhone creates bloated, slow apps"

Do you have any evidence for that? Do you know which of the seven apps in the store use this technology? I don't see how you could know that a binary produced using Flash is necessarily larger or slower than one produced by Xcode. They're using the same compiler, after all.

Either we want an entirely locked down platform that Apple have total control over - and my understanding of your position on that from reading you blog is that you don't believe that - or it should be open and let quality win the battle.

My experience of the app store is that people blame the *app* not the platform. Often, they blame the app when the problem is actually Apple's fault. I've heard people complain about crashy iPhone apps, but not about the device. Maybe I'm just lucky in my friends.

Cheers,
James

Jeff LaMarche said...

James:

Yes, Adobe links to all seven apps in their FAQ, I downloaded several of them, tried them, then unzipped the .ipas and took apart the bundles to see how they were built.

I feel fairly confident in stating that the apps are bloated and slow compared to what the same app done natively would be. Maybe that will change, but that's the current state of the situation with the application's Adobe chose to highlight.

higgis said...

Interesting - and if you've looked at them, I'm sure you're right about the bloat. Perhaps when it exits beta it will be better.

If the product is *objectively* worse than the equivalent produced using native tools, then I'm against it, and any rational developer would be too (unless they have such a massive code base that porting would be a big problem, I suppose).

Yedrzey said...

Missing important point here the only way for windows developers to develop apps for iphone is to use MonoTouch / Adobe.

Rubish applications developed for quick buck can be developed in obj-c as well as in C#/Flash or whatever comes next.

Average developer with average attention to details have better chance to develop good app in environment where there is garbage collector to clean up after him than same dev in Obj-C.

Apple charges every dev $100 / year even if you don't earn any money on your apps so I'm not supprised people are trying to sell even crappy apps to get their money back. Honestly why there is no option for developers who want to develop for themselves for eg. to learn?

Jeff LaMarche said...

Missing important point here the only way for windows developers to develop apps for iphone is to use MonoTouch / Adobe.

Don't think it's a missing point at all. Why are people who don't even want to use Apple's computers entitled to develop for Apple's phones? Does Microsoft publish Visual Studio for Mac? Do they provide a way for Mac users to create Windows Mobiles apps? Of course not. C'mon, that's a silly argument.

Rubish applications developed for quick buck can be developed in obj-c as well as in C#/Flash or whatever comes next.

Of course they can. Because a bad thing can be done is no justification for making that bad thing easier to do.

Average developer with average attention to details have better chance to develop good app in environment where there is garbage collector to clean up after him than same dev in Obj-C.

Frankly, I'd rather leave "average developers" to other platforms. Apple had a very good reason for not including Objective-C's garbage collector on the iPhone, which is because the iPhone is a memory constrained device. Adding another level of complexity and tacking on a garbage collector doesn't negate this simple fact, it makes the problem worse.

Apple charges every dev $100 / year even if you don't earn any money on your apps so I'm not supprised people are trying to sell even crappy apps to get their money back. Honestly why there is no option for developers who want to develop for themselves for eg. to learn?

Bullshit. You can join the free SDK program to learn. You don't need to spend money to start at all. Your get Xcode, the SDK, the documentation, and the simulator all for free you just can't distribute your apps on the App Store.

Yedrzey said...

Don't think it's a missing point at all. Why are people who don't even want to use Apple's computers entitled to develop for Apple's phones? Does Microsoft publish Visual Studio for Mac? Do they provide a way for Mac users to create Windows Mobiles apps? Of course not. C'mon, that's a silly argument.

If I want to buy iphone and write an app why I'm forced to buy MAC as well ? I don't say Apple is supposed to support windows, what I say is there should be open standard for SDK and tools so open source IDE for windows/linux can be created. MS doesn't support VS for MAC but their .Net framework runtime is open standard that's how Mono was created. Why Apple wants to protect it's platform instead of spreading it? Even you say Apple might tweak their system so 3rd party apps developed in non-native enivornment might stop working - why??? Instead of tweaking it in a way they work smoothly?

Bullshit. You can join the free SDK program to learn. You don't need to spend money to start at all. Your get Xcode, the SDK, the documentation, and the simulator all for free you just can't distribute your apps on the App Store.

Not quite bullshit SDK is free and simulator as well but what if I want to upload my app to my OWN phone? I write application and I can't even test it on my own phone without paying license.I support the idea to pay $100 for using appstore but if you don't put there anything you should be able to write application for youself without paying.

Jeff LaMarche said...

If I want to buy iphone and write an app why I'm forced to buy MAC as well ?

First of all, it's not an acronym. It's a Mac, not a MAC.

what I say is there should be open standard for SDK and tools so open source IDE for windows/linux can be created.

OpenStep is an open standard. There's a desktop implementation of it called GnuStep. It's open, go ahead and create your own mobile development tools based on it.

MS doesn't support VS for MAC but their .Net framework runtime is open standard that's how Mono was created.

Yes, Microsoft has been so embracing of open standards and the open source movement.

Why Apple wants to protect it's platform instead of spreading it?

I'd say those two go hand-in-hand to Apple. The reason it's been popular is because the control the experience completely. Opening it up would be good for competitors, not necessarily for Apple. Fundamentally different business model then, say, Microsoft.

Not quite bullshit SDK is free and simulator as well but what if I want to upload my app to my OWN phone?

That's not what you said. You said there was no way to learn to program the SDK without spending.

Can you install programs on your Windows Mobile phone without paying any money?

Alex said...

Yeah I have to agree with you a lot here Jeff. I think if people want to develop iPhone apps then should just suck it up and learn how to use Obj-C instead of doing questionable (imo) flash based apps. Its not like learning to use the iPhone SDK/ obj-C is even all that hard. Hell, I was completely new to the language but it only took about 4-5 months of spare time (read: after day job) work to develop and publish to the store my first iPhone game, Shine. If people can't invest even a small bit of time to learn how to develop for a platform, what confidence should we have that they will bother to learn how to make quality apps.

A glut of poorly made, bad performing apps that break all the time is bad for the whole community. From my experience most users don't make fine grain distinctions, if a couple apps they download are bad, then they are going to be more hesitant to spend money in the future, which hurts all of us.

Gargs said...

I believe there are both sides to this argument, both compelling.

That said, are we also going to protest against the numerous other toolkits available for iPhone 'game' development like Torque and GameSalad? In both those cases, it's almost trivial to write a game without using a Mac. Or, are we just speaking against Flash and .NET, which happen to be technologies that didn't originate at the Apple campus, but also seem to come from companies that generally don't have a lot of goodwill in the Apple community?

No one is going to write productivity apps using Flash (not saying that it's impossible). I see most developers using Flash to create games for the iPhone, and I think the Flash toolset is much more developer friendly than what the SDK provides. In fact, I am willing to wager that most successful games on the iPhone use some sort of third party framework/developer suite/or even IDE.

I agree with the sentiment that serious developers need to learn the platform before they go about hacking it to bits and pieces just to fit their current knowledge around it. As a full-time Java developer, learning Objective-C and Cocoa has been the most fun and enlightening thing I have done in a very long time.

Jeff, if MonoTouch can have garbage collection for the iPhone, is there a reason to believe that Objective-C in a future coming wouldn't support it, too?

Jeff LaMarche said...

Jeff, if MonoTouch can have garbage collection for the iPhone, is there a reason to believe that Objective-C in a future coming wouldn't support it, too?

I think it's almost certain that we'll get Garbage Collection at some point. They didn't exclude it because they couldn't get it working, they excluded it because the tradeoff was felt not to be worth it - the overhead was too much for the benefit you got.

The two factors on modern computers, from what I understand, that make GC more efficient than not using GC is multiple cores and processors (reaping can happen on non-main thread) and spinning media (there is latency when disks spin up or when I/O is blocked, that time can be used for reaping).

Neither of these exist on the iPhone. File system is flash memory and the processor is single-core. I doubt we'll ever get spinning media, but we will likely get a second core. Once multiple core iPhones are standard, then I think we'll get it. Before then, I don't think it's worth the tradeoff.

But, maybe I'm wrong - maybe just a faster processor will be enough.

higgis said...

Certainly .NET had Garbage Collection long before multiple cores. The problem then was that an excessively long GC session could cause a stutter in the application - say 1 sec - which degraded user experience. You often ended up with hard to find deadlocks when you deployed to a machine with multiple CPUs.

Miguel de Icaza says that the MonoTouch runtime adds 4MB of overhead for its runtime, but also that calls from C# to C# are faster on the device than ObjC to ObjC calls on the device. That has the *potential* to improve user experience.

Bibhas said...

Hard to believe that Apple will actually let people write iPhone apps on a PC.

Adobe does not mention a formal agreement with Apple on their site. I think this whole thing is going to turn into a big scandal IMHO.

Jeff LaMarche said...

Miguel de Icaza says that the MonoTouch runtime adds 4MB of overhead for its runtime, but also that calls from C# to C# are faster on the device than ObjC to ObjC calls on the device. That has the *potential* to improve user experience.

4 Megs on a first generation iPhone or an iPhone 3GS could be a considerable percentage of the memory available for heap allocations.

How are calls from C# to Objective-C? Because they can't get around calling UIKit functions. They might be able to avoid Foundation, to some extent, but not UIKit.

I'll also be curious to see if that speed holds true after we get the hybrid vtable implementation from Snow Leopard.

(Note - I do NOT actually know we are getting it, I'm just making an educated guess)

I also wonder how it compares to Objective-C++ method dispatching.

I have to admit that I'm highly skeptical of any claims that adding complexity and adding layers of abstraction will make the overall experience faster or better. I'm not concerned with individual statistics in a vacuum, show me the real world consequences.

Would be great if they've figured out a way to do things faster than Obj-C, but I'm skeptical until I see proof.

Jeff LaMarche said...

I meant iPhone 3G, not 3Gs in that last comment.

Me said...

I have to admit, being a developer who has had to get up to speed on a number of languages in the last 15 years of working, I'm really intrigued by the language side of the debate around iPhone development.

Objective-C is the "natural" language to use on the iPhone because the libraries one must consume to generate a working app on the iPhone that make use of any SDK components are Objective-C libraries.

I have liked using Objective-C when I've used it. But I'm not going to pretend that in the end I'm not just using a tool that spits out an executable consisting of ARM instructions.

I don't really care at all what language the compiler receives at the front end so long as the ARM instructions at the end consist of a nice, well-behaved application.

You've noted that at present the results of their compilation seem to be rather bloated and slow, which is quite possibly the case, but there's nothing that states that "by definition" ActionScript compiled to ARM instead of to AVM instructions is necessarily shitty.

In fact I'd say they've chosen a very sane plan to pursue this by leveraging LLVM (heck even AAPL is throwing some tech talent at LLVM). Adobe already had an AVM code generator for LLVM so that they could use experiment with using the C++ front end to compiled code to run in the Flash Player, so why not also build something that either takes AVM bytecode and compiles to ARM, or go the ActionScript -> LLVM IR -> ARM route??

The other puzzling technical question I'm seeing in this debate is with respect to reverse engineering the SDK. The libraries are Objective-C libraries. The only thing one needs to do so far as I can see is see the documented interfaces for the Objective-C objects (that is, what messages do they respond to) and they are free to use the Objective-C runtime to send those messages and support the appropriate runtime functions so that their objects can in turn receive messages. That's one of the joys of all that tasty late-binding goodness!! That is, it's no incredible technical feat to call ObjC objects, nor to provide an ObjC interface to your own code.

On the SDK violation front, the path certainly doesn't seem to be clear, but I don't think there are too many, if any, technical issues (perhaps with code signing assuming AAPL does something prioprietary). The issues I'm curious to see how they play out relate to whether this violates allowing someone to use the SDK on non-Apple branded computers (or however they word the restriction) by allowing them to generate code which calls into UIKit, etc even though none of the SDK code actually needs to reside on the machine where the code was generated.

I suppose my only other comment, and again it's language related, is that this debate also seems to have a tinge of "programmers who use [language-X] are inherently better than programmers who use [language-Y]." I want my apps written by competent developers using tools which ultimately output sensible instructions for the target platform of their apps. I don't have a care in the world for what formatting the text files had that the programmer used as input to their compiler. Note that I am not making the same argument as "users don't care what it's written in" because that argument frequently extends to the fact that users don't care about the final instructions being executed. I care greatly about the final instructions being executed, just not so much about how they were generated. To think otherwise, I think, is just insisting on a different hammer for the hammer's sake.

mdi said...

Hello,

A tweet does not do justice to the memory usage.

4 megs is the on-disk footprint that comes with Mono. But unless you use the feature, the feature is not paged into memory.

We still have some work to do to improve linking and that should reduce the on-disk footprint.

The memory footprint has not been a problem as far as I know with game developers that have used Mono to develop games using Unity3D.

There are some 250 games on the AppStore built with Unity3D, and 5 of the top 100 apps have been built with Unity3D/mono.

K. A. Barber said...

I predict Adode to profit greatly from fostering this flavor of "hammer development". That is if they are left to grow this particular product line unhindered. Dividing the iPhone developer community and obfuscating the sharing of code and ideas is an excellent strategy of attack to the Apple mobile device juggernaut.

Frankly, I don't blame Adobe for wanting a piece of the pie. It is so hot and delicious right now. They in fact would love for there suite to be the de facto standard for all mobile device application development regardless of platform, whether it should be or not.

I a have happily used flash on past projects and recognize its usefulness for certain things. I just don't think flash is what the iPhone platform needs write now.

Sadly, it will be the development community that will suffer in the end as fragmentation and "fanboyism" slowly eat away at cooperation.

Has anyone discussed the price barrier to entry for the adobe suite? I hear a lot of people complaining about buying Macs but last I saw the price of the collection of adobe products needed is just as much as buying a new computer and paying the $100 usage fee.

K. A. Barber said...

I purposely left out MonoTouch from my previous comment as I think that the Adobe offering has a far greater chance at wide spread acceptance than MonoTouch.

Jeff LaMarche said...

mdi:

Thanks for the information, that's interesting. I actually have a lot less issues with MonoTouch - I think C# and Objective-C have a lot more in common than Objective-C and don't find it nearly as hard to believe that you could generate an efficient application using it. I think it's interesting that people would choose to go that route - if I were going to port an App to Windows, I wouldn't try and use Objective-C, even though I'm more comfortable with it than C#. I just find it an interesting mindset, to be honest. But if the generated applications are efficient, I don't really have a problem with it. I'm more bemused than anything.

On the other hand, I have strong opinions about ActionScript and Flash/Flex, and first hand evidence so far seems to be that the applications generated by Flash are not great - they are bloated and not that responsive.

There's also a huge number of Flash games that are going to flood the App Store if this goes forward, which is going to degrade the experience for users and developers. Personally, I would like to see less crap on the App Store, not more.

It's not so much the individual impact of a single application so much as the potential problems for end users and the community that Flash on iPhone opens up that concerns me. There are many Flash developers, many of whom are primarily designers and who don't understand a lot of fundamental aspects of software development. In sum total, there are probably tens or hundreds of thousands of crappy little Flash apps out there there this will allow to be ported. Yes, there are some good ones, but there are a lot more crappy ones.

I don't see that being good for iPhone users. While individually, most of these apps won't be able to compete, they will increase the sheer volume of apps on the store, increasing noise and making it harder for worthy developers of any stripe to get their work noticed and making it harder for anybody to make a living off of the app store.

I know Flash devs want a piece of our pie, but I don't honestly believe that letting them have it is going to be good for anybody but them, and I don't see why it's not enough for them to be able to deliver their crappy little apps on every desktop platform there is.

Nicolas Goles said...

I also think Adobe would make damage to the community , what if all the applications made with their tools broke after an update? thousands of applications, only being fixed after the corresponding updates ( 1 week or so, assuming it would take a week because of the Hog that the approval process could get ).

I think the barrier of entry of 100 USD is a joke, that argument is SO stupid. To the guys thinking like that, have you tried to develop on Nintendo DS ? Sony PSP ? Do you know the barrier of entry to those platforms and the quality of the tools that are given by Nintendo and Sony ?

I think the guys saying "Apple doesn't let me put my app on the phone, so I have to pay 100 USD", and think that's actually bad, should really look what other companies are really offering.

About the flash games, it WOULD suck, they would be bloated, and slow, battery sucking applications ( I can't be 100% positive on this but I'm willing to bet high on it), that WILL impact the image that the users have of the iPhone as Jeff stated.

I think apple should take the correct measures now, because later, after some bad stuff happen, could be too late.

Matthew Fabb said...

K. A. Barber, regarding price, Flex Builder 3 standard edition is just $249. I imagine the rebranded Flash Builder 4 will be around the same price. Seems that at first only the beta of Flash CS5 will compile SWF files to iPhone binaries. However, Adobe's Ted Patrick has already blogged about creating pure ActionScript3 projects (all code no timelines) with Flash Builder 4 and compiling them into iPhone binaries.

Also in that same blog post Ted Patrick mentions says:
"These samples were built about 16 builds back and much has changed. Binary size is an issue the team is working on. The swf is translated to LLVM and then grafted with the flash api implemented in native code."

So it looks like the current examples up on the iPhone store is just where Adobe is and it's still a work-in-progress.

Mostly Torn said...

It's a thorny issue. I think the title of this post captures it right though. A "developer" should care whether the tools are producing efficient code, or whether they will be producing a good end-user experience.

But as a business decision for Adobe, I can't fault them for what they've done. Flash is their product, and they want to get it into the hands of as many developers as possible. Assuming no laws were broken (or terms of Apple's SDK license), it makes perfect business sense. Public held businesses are supposed to be all about doing the best they can at increasing the company value (while working within the law).

Sure, it sucks that we iPhone developers will see a flood of flash-generated apps hit the store, further increasing competition, but that's life as a developer. Any successful platform will get milked by every profit seeking entity that is in the software business. It's a fact of business. People go where the money is.

The best defense you have is to continue to be the best skilled developer / designer possible and cope with the increased competition. The iPhone platform wasn't intended to be an exclusive club. If Apple wanted it that way, they'd make the developer sign up costs a lot higher.

Given the low cost of entry for the iPhone, we are already seeing a ton of crap being released on the iPhone, regardless of development platform used. I just hope the app scene doesn't run into the same problem Atari did years ago with the 2600. Too many crap games eventually made for jaded users and software sales tanked.

Hunter Hillegas said...

This reminds me of discovering a fantastic indie band and just loving them, then hating it when they blew up and became super popular and everyone was into them.

Not entirely rational but incredibly common.

BTW, Flash sucks. :)

an0 said...

Totally agree.
Want to take out money? Put in your time and energy first.

Iain said...

I think you make some good points about why Flash generated apps might not be as high quality as obj-c apps. But when you talk about not allowing these technologies, it does just sound like protectionism. I say let the market decide. By the way, it's Flash CS5 not Flash 5. Flash 5 came out 9 years ago.

bluescrubbie said...

"If you can't be bothered to learn that, to understand the iPhone experience completely, that tells me that you just want a piece of the pie."

Cut the sanctimonious BS.

If Apple cared enough about developers, it would replace its 30-year-old, cryptic, long-slog-learning-curve, bolt-onto-C language with one or more human-friendly languages; maybe even (gasp) supporting ones that enjoy wide support!

Or would that violate Apple's entrenched "my way or the highway" mentality?

Even in some alternate universe where Apple behaves in an inviting manner instead of expecting everyone to adapt to them, you can still take heart - there would still be a significant framework to learn. That would ward off all of those lazy money-grubbing would-be iPhone developers.