Today's license changes and Unity

Quote:3.3.1 â€” Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

3.3.2 â€” An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise. No interpreted code may be downloaded or used in an Application except for code that is interpreted and run by Apple's Documented APIs and built-in interpreter(s).

SDL and scripting code have always been verboten on the iPhone.

You can't use dynamic libraries on the iPhone. All code has to either be in Apple's frameworks, or statically linked inside your executable. No dylibs. No scripting. SDL is LGPL licensed, which requires linking against a dylib. If you're using SDL on the iPhone, You're Doing It Wrongâ„¢.

Apple's position on iPhone apps has always been either:
1) write a web-app and do whatever you want or
2) Use Xcode and other Apple devtools. Use C, C++, or Obj-C. Use Apple's frameworks exclusively.

If you were using Unity, or MonoTouch, or planning to use Flash, or whatever, you weren't doing one of the above.

EDIT: Really, in my mind this is similar to the early days of Mac OS X. Apple kept saying, "You should really be using Xcode and Cocoa for OS X apps." A lot of people kept on with Carbon and CodeWarrior (*cough* Adobe) or other older technologies, and later got screwed. (Intel transition, 64-bit, etc). If you're not using an Apple-graced technology, and you don't own or have access to the code, you're setting yourself up for heartache later.

Bachus Wrote:You can't use dynamic libraries on the iPhone. All code has to either be in Apple's frameworks, or statically linked inside your executable. No dylibs. No scripting. SDL is LGPL licensed, which requires linking against a dylib. If you're using SDL on the iPhone, You're Doing It Wrongâ„¢.

Well, you can buy a commercial SDL license and statically link - but SDL doesn't make much sense (or actually make things any easier) on iPhone OS IMHO.

The 3.3.2 clause is another PITA for game developers - most engines/middleware are driven by interpreted scripts or dlls. I can understand why they wouldn't want unverified downloaded code executed, but I don't see how executing external code bundled with your app is any different than executing static code in your app. If it's vetted code it's vetted code - who cares how it's loaded?

AnotherJake Wrote:To me, and many others, it looks like Apple has very little interest in the quality of apps on the iPhone or whether anyone is successful or not. Instead, it looks like all they want are as many apps as they can and to see tens of thousands of developers clamoring to be on iPhone. I think it's ridiculously stupid for them to present that attitude. Why crap on the developers? Why not actually take care of the developers instead? Why not treat them with a little respect? Would that really hurt them somehow?

But if they did want as many apps as possible, why ban third party software?

It can not be to make the apps better, it will most certainly make them worse. What they will do is to get rid of interesting, complex apps, the ones that need third party libraries.

I guess the goal is to have as many unique apps as possible. And the ban against thrid party software is most likely legalese fluff that makes it possible for Apple to kick out any significant technology they like, which means Flash. But it also means that investments in producing third party tools for the iPhone are not likely to be made. Apple's signals is that they will stop them, so if you make something that gets big, your only chance is that Apple buys it.

This whole mess is pretty depressing. I hope Apple makes some official clarification, giving us a clear bordeline between allowed and disallowed that doesn't ban all common programming practices.

Skorche Wrote:The problem is that Apple is holding all the secret keys to make the best software. You can't use the APIs that they are allowed to use. You can't make software that fills a similar role to Apple's (if they decide that they don't want the competition). Implementing functionality similar to their apps (even at a superficial level) has lead to rejections as well.

Absolutely. How many improvements to, say, the Finder are rooted in an innovation pioneered by a third party dev? Many.
What if there was no other email apps on the Mac? Just because I'm happy enough with Mail.app doesn't mean we shouldn't have Eudora, Exchange, etc.

Skorche Wrote:At the same time they let so much shovelware on the iPhone that it's ridiculous. Bad terrible UIs diligently written in XCode with Cocoa, buggy apps that crash constantly, programs rife with memory leaks, etc.

This is the biggest problem. If they're getting down on tools - whether it's Flash-created apps that may potentially eat battery, or other things - the entire platform is better if Apple simply rejects most of the crap out there. Of course, the platform's overall app count is incredibly important; it has been used in advertising as an advantage over other mobile platforms. Of course, when 80% of the apps are pretty much pure junk from get-rich-quick artists (or perhaps just hobbyist coders who really haven't understood the UIs of the iPhone), then that advantage becomes a lot smaller. That doesn't mean the other mobile platforms won't have a bunch of junk apps though...

What if Apple could advertise "Our apps go through a 30-point approval process to ensure your time is not wasted." Like a car checkup to make sure the car runs well, this would be an app checkup to make sure the app is good. The main issue with that? Apple would need to publish guidelines on exactly what it is they test, and eventually the shovelware artists would figure out a way around it... but with common sense, Apple could just revise and publish new approval processes.

funkboy Wrote:Absolutely. How many improvements to, say, the Finder are rooted in an innovation pioneered by a third party dev? Many.

And there are many that havn't made it to the Finder yet, despite huge advantages. Default Folder X is my favourite. Ever since its predecessor "Click! There it is!", I have felt limited on any Mac without it. But if Apple had stopped that possibility, I would still have to mess with the ineffective built-in system.

Quote:This is the biggest problem. If they're getting down on tools - whether it's Flash-created apps that may potentially eat battery, or other things - the entire platform is better if Apple simply rejects most of the crap out there. Of course, the platform's overall app count is incredibly important; it has been used in advertising as an advantage over other mobile platforms. Of course, when 80% of the apps are pretty much pure junk from get-rich-quick artists (or perhaps just hobbyist coders who really haven't understood the UIs of the iPhone), then that advantage becomes a lot smaller. That doesn't mean the other mobile platforms won't have a bunch of junk apps though...

What if Apple could advertise "Our apps go through a 30-point approval process to ensure your time is not wasted." Like a car checkup to make sure the car runs well, this would be an app checkup to make sure the app is good. The main issue with that? Apple would need to publish guidelines on exactly what it is they test, and eventually the shovelware artists would figure out a way around it... but with common sense, Apple could just revise and publish new approval processes.

You sure have a point. An official guideline on what the accept or not, right? It could make it easier to foresee the outcome, whether you are welcome or not, and decide that before you go into expensive polishing stages.

They should totally ignore what tools you use. None of their business. Just inspect the result. If it uses too much CPU for what it is doing, or if it is plain ugly (e.g. uses a foreign widget set), reject on that, but not on what language or libraries it uses.

Ingemar Wrote:But if they did want as many apps as possible, why ban third party software?

That's a good question, and definitely pokes a hole in my theory. Still, why do they then allow the massive amount of shovelware? This situation is really hard to comprehend.

Ingemar Wrote:This whole mess is pretty depressing.

I fully agree!

Also, I think we've all been wondering why they haven't published an official document on their review process since the beginning. It would speed up the approval process for everyone because there'd be less rejections/resubmissions.

Personally, I've never had a rejection out of the many submissions we've done (heck I even got IAP through on the first try), but I still wish they had the guidelines so there would be less rejections/resubmissions plugging things up and slowing me down too.

Finally, I'm thinking about starting a Keith Olbermann-style counter of how many days the iPad has been out and still not allowing browsing for other apps than what's hot, like the number of days since mission accomplished in Iraq.

Frank C. Wrote:Well, you can buy a commercial SDL license and statically link - but SDL doesn't make much sense (or actually make things any easier) on iPhone OS IMHO.

The 3.3.2 clause is another PITA for game developers - most engines/middleware are driven by interpreted scripts or dlls. I can understand why they wouldn't want unverified downloaded code executed, but I don't see how executing external code bundled with your app is any different than executing static code in your app. If it's vetted code it's vetted code - who cares how it's loaded?

So how did Unity get around 3.3.2? (That's been around for ever).

You know SDL might not be banned but the way some people are discussing it it might just prompt apple to include it in the ban.
I usually go along with Apples decisions, most are logical and trying to keep with good programming practices even though I don't agree with then. Such as not using private
api's but this 3.3.2 clause seems like a knee jerk reaction aimed at flash which could have a ripple effect.

This stuff about cross compilers producing inferior code is garbage, Back in the day when I was in engineering schools, we use to write our c and pascal compilers (yes I wrote compilers they are not some mystical beast like a unicorn) then compile the compiler code with the new compile which produced tighter optimized code. We also used to build intermediate little "Control" languages and interpreters into our code.

Todays systems with all their complexity are more vulnerable than ever to hackers, why , because so many programmers only know how to program at a high level that they don't know how to guard against old school programmers who are going to come in thru a very low level back door. I might spot it but I promise you 70% of the coders out there won't.

SDL for iphone is not and never will be a compatibility layer, for safety any reference to that terminology should be removed. The licensed version of sdl is just a statically linked library of c and c++ code.

Any so called compatibility level is simply achieved by a jump table that translates sdl methods to iphone api methods. if Steve jobs considers that a violation of 3.3.2 then opengl itself is guilty too.

3.3.2 is clearly aimed at tools such as montouch, freepascal and adobe cs which interpret foreign code such as actionscript or c# into objective-c compilable code. clearly that should be the demarcation if there should be one at all.

SDL on the iphone works because it is a layer between sdl and open gl, it is almost a one to one, sdl commands map to opengl commands or a set of sdl commands, you can get the exact same effect building your own methods, its just someone already took the time to do it for you.

SDL's 1.3 implementation of open gl is so "Soft" in fact it makes it a pain to create anything resembling an iphone applications. understand I am not criticizing sdl and the overall package is much better than the "subset" intended for iphone and most importantly with abiet some extra work you can move games and other applications from other platforms WHICH DOES make it a powerful class library .

But the way sdl creates its windows and eagl views in code makes it harder to add common iphone ui elements like nib files and subviews. It can be done, but I am finding to my dismay it can't be done in a generic way, every app requires the code to tailored in a slightly different manner.

Trying to write portable code on the iphone platform is an observitiy, Maybe 3.3.1 is Apples's unique way of admitting they designed a system that is hostile to portable code, building apps on the iphone is all about customizing view controllers and stacking views and subviews, you can do all that in code but than you have to go out of your way to mirror all the hidden initialization you get from using IB.

Running sdl in the manner prescribed by the documentation would definitely feed an Apple argument to ban it, it uses no nib files (which isn't exactly that bad, Erica Sadun wrote an entire iphone "cookbook" full of examples that only use a main.m without any nibs. But nibs do help in loading and unloading view controllers which you will find is true when you try to convert an sdl program to use splitview controllers on the ipad. Like me you are going to have to reintroduce the mainWindow.xib at startup otherwise you might get the splitview to show with some trickery but you won't get the popoverview to work correctly.

treating sdl as just another statically linked library will probably be ok. Thats my opinion but if its wrong then virtually EVERY statically linked library could be at risk which I don't think Apple intends to do.

Apple has always had access to the source, but based on my experience with similar work situations it doesn't seem feasible they have the reviewer staff to go through every line of code. My guess is they just use the static analyser tools UNLESS they suspect from the behavior of the app that somebody is doing something weird.

Otherwise there would not be so many apps in the apps store that obj load the core surface private framework. Any apps that does on Device video encoding (not decoding) or video sharing ie. ivideocamera etc uses that api.

An app that uses absolutely no UIkit components could fall under that suspicion category.

Sadly I myself have come up with a contingency plan for my own apps, mind you it would set my development cycle back a month or two but I could save my apps.
I have analysed the sdl methods I used, those could be fairly easily duplicated as in app classes, again SDL is just a class lib of methods written in C and C++ which could easily be duplicated locally.(C++ is officially ok) That would save my particular apps would others be able to adapt that strategy I am not sure. technically renaming the static library and the main methods would have similar effect, that is how absurd this who 3.3.2 business is.

SDL is about as vanilla as it comes to using approved api's, I have more fear of other libraries I have used such as 320 than sdl, it doesn't seem to use any private api's anywhere.

I know I've been rambling on but this whole business is going to be confusing until Apple clarifies its vague language, which I suspect they will, when that happens I think it will be clear sdl will be ok but freepascal, monotouch etc are clearly out. Which I think shows they are being childish . Also arguments about those cross-compilers producing terrible code are just plain stupid.

michelleC Wrote:Also arguments about those cross-compilers producing terrible code are just plain stupid.

I think we all agree about that -- although it is still certainly possible to screw that up too. I don't even understand why they'd complain about interpreted code. I can make really fast interpreted code and make a better app at the same time. If their problem is really all about Flash, I wish they'd find a better way to fend it off, rather than this sleazy, crippling, back-door legal fungus.

Ingemar Wrote:An official guideline on what the accept or not, right? It could make it easier to foresee the outcome, whether you are welcome or not, and decide that before you go into expensive polishing stages.

They should totally ignore what tools you use. None of their business. Just inspect the result. If it uses too much CPU for what it is doing, or if it is plain ugly (e.g. uses a foreign widget set), reject on that, but not on what language or libraries it uses.

Absolutely. Published guidelines is the #1 improvement for a good developer experience. Even if they change every month, fine, but at least let us know what will be judged.

Why Apple hasn't done this yet is because of the uproar it would likely cause once they wanted to start changing the guidelines. However, if they just start changing them a few times at the beginning, we'll all get used to it (though still complain), and they can get almost the same ability to change their mind (yes explicit apps, wait no explicit apps but bikini apps, okay no bikini apps, okay maybe a separate part of the store for them, etc.).

What I mean is, how many iDevgames have occurred where we argued over the "must only be Xcode" rule and its associated evils?

<insert maniacal laugh and hand rubbing routine>

Anyhow Steve's point of diluting the value of iThing exclusivity by having apps that run on any device has some point. A game/software made in Flash can be run in a web browser, there is no point in getting an iThing to use it. Make something for Windows and the thing can run on 100% of the world's computers, by 100% of the world's software pirates.

Steve's point about people like Adobe controlling the platform has a point as well.
Imagine the situation where 60,000 apps are made in Flash.
Apple makes massive changes and improvements to the iPhone OS and something breaks in 30,000 of these Apps. Adobe is slow to respond, but people don't blame Adobe, they blame Apple. Just like the idiots in last month's Mac world blaming Snow Leopard for breaking their Appletalk network (good gravy!) and their ten year old printer drivers.

Since Apple is technically selling both the device and the software, they are stuck with the "I want my money back" complaints, while Adobe gets to spend their resources updating their Windows based software.

The thing to consider here is that change is coming to the devices and the SDK.
Consider iPhone OS 4.0 to be at the toddler stage that Mac OS 4.0 was in 1987.
Apple is planning ahead, while the SDL people and the Flash people can't possible know what Apple knows.
Things made those other tools/methods will break.
Apple is heading off the day where 65,000 apps stop working because they are made in some archaic tool and abandoned by their developer.

Ingemar Wrote:But when Apple makes 65000 apps stop working, because they introduce some bug in the OS, what is the difference? Apple doesn't have a good track record in this respect.

They've figured out a way around this though. All they had to do was make it so that customers couldn't browse for any game except for the 40 or so that they wanted the customer to see. That way if the other 64960 stopped working, nobody would notice. Genius!

SDL is a statically compiled c and c++ library pretending to be some kind of compatibility layer.

Flash CS like montouch takes a non iphone native languate like c# or actioncode and produces object code. Or pcode which can be compiled by the gcc compiler.

Apple may have some point in fearing this.

Comparing sdl and flash/monothouch are like comparing apples to oranges.

The former is not covered under 3.3.2 because it is just a collection of class libs, it if it does somehow get banned it will be by perception alone by reviewers who don't know anything about code compilers.

Also it will set a dangerous presidence for any 3rd party library.

If I include a jumptable to allow my library more compatibility with other platforms does that make it a banned framework, give me a break.

igame3d Wrote:Is it irony or is it karma to see this conversation happening?

What I mean is, how many iDevgames have occurred where we argued over the "must only be Xcode" rule and its associated evils?

<insert maniacal laugh and hand rubbing routine>

Anyhow Steve's point of diluting the value of iThing exclusivity by having apps that run on any device has some point. A game/software made in Flash can be run in a web browser, there is no point in getting an iThing to use it. Make something for Windows and the thing can run on 100% of the world's computers, by 100% of the world's software pirates.

Steve's point about people like Adobe controlling the platform has a point as well.
Imagine the situation where 60,000 apps are made in Flash.
Apple makes massive changes and improvements to the iPhone OS and something breaks in 30,000 of these Apps. Adobe is slow to respond, but people don't blame Adobe, they blame Apple. Just like the idiots in last month's Mac world blaming Snow Leopard for breaking their Appletalk network (good gravy!) and their ten year old printer drivers.

Since Apple is technically selling both the device and the software, they are stuck with the "I want my money back" complaints, while Adobe gets to spend their resources updating their Windows based software.

The thing to consider here is that change is coming to the devices and the SDK.
Consider iPhone OS 4.0 to be at the toddler stage that Mac OS 4.0 was in 1987.
Apple is planning ahead, while the SDL people and the Flash people can't possible know what Apple knows.
Things made those other tools/methods will break.
Apple is heading off the day where 65,000 apps stop working because they are made in some archaic tool and abandoned by their developer.