Today's license changes and Unity

I'm pretty sure that they don't want any cross platform UI libraries regardless of what language they are written in. If somebody decided for some reason to make an iPhone version of GTK or WxWidgets, I'd imagine that to be in the same boat. Cross platform "compatibility layers" are bad in Apple's book because they allow you to make non-standard UIs. Forget the fact that you can trivially make a bad or non-standard UI using Cocoa Touch. There are plenty out there and Apple doesn't seem to care about banning those apps. While SDL is going to contribute much less to the user experience than a UI library, who cares as long as the finished product is functional and usable.

@iGame3D
And as for Xcode... Most people around here really dislike it. Since starting iPhone dev, I've grown to hate it even more as it tries to do all sorts of extra magic for me. When something goes wrong with a project's build settings it can make it really difficult to fix.

Also, what makes you think that 65k applications written in Objective-C aren't going to break. Given the economics on the app store right now, how many of those 65k applications are still making enough money to justify fixing them? 90% of them were probably abandoned as soon as they were released.

Skorche Wrote:I'm pretty sure that they don't want any cross platform UI libraries regardless of what language they are written in. If somebody decided for some reason to make an iPhone version of GTK or WxWidgets, I'd imagine that to be in the same boat. Cross platform "compatibility layers" are bad in Apple's book because they allow you to make non-standard UIs. Forget the fact that you can trivially make a bad or non-standard UI using Cocoa Touch. There are plenty out there and Apple doesn't seem to care about banning those apps. While SDL is going to contribute much less to the user experience than a UI library, who cares as long as the finished product is functional and usable.

That's exactly what I'm thinking, and as a game developer that apparent viewpoint of Apple's drives me nuts!

Why do they have to do a blanket license agreement which covers all apps, when clearly games are in a completely different boat in terms of UI? There is simply no way I can guarantee a fit with their UI guidelines in what I see as a work of art (a game). I mean, c'mon! Dude, if this is the way it's gotta be then why don't they require that all movies and books use native Apple GUI elements in their works? Yes, that would be ridiculous, but isn't that what we're talking about when it comes to games too? Not to mention the fact that their native UI widgets won't run efficiently on top of an OpenGL view in the first place. Believe me, when I first started iPhone game dev I was all for making it "fit" with the iPhone, but as time has gone on, it has become crystal clear to me that it simply isn't practical with games.

Games need artistic latitude. I can understand if they want to restrict "regular" apps, but why do this with games as well?

I'm sure SDL would be totally A-okay to use if the SDL license and iPhone dev agreement weren't in disagreement. If the SDL license let you statically link it you'd be in the clear. That said, is SDL even ported to the iPhone? Doesn't seem like it'd be good for much.

igame3d Wrote: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.

That's a great article on this whole situation. Read the "WHY DOESN'T APPLE LIKE 3RD PARTY RUNTIME ENVIRONMENTS?" section to see why Apple did this. Apple isn't going to let another company dictate to them about app development. Period. End of story. Of course, why any developer would want to use some third-party go-between dev tool like Flash or Unity in the first place is beyond me.

Bachus Wrote:Of course, why any developer would want to use some third-party go-between dev tool like Flash or Unity in the first place is beyond me.

Yes, for a "regular" app, Flash or Unity would not make sense, but again, for games, what would be the point in the restriction?

I can understand why someone would want to use Unity for games, because it's a fantastic game engine. I can understand why they'd want to use Flash for games as well, since it's arguably easier to get into than full-on C/C++/Obj-C from the ground up. And why should they be restricted from using them for games? I don't think they should. You get most of the processor in a mostly non-multi-tasking environment. If you can make your game fit on that processor and graphics accelerator then that should be the only technical restriction [edit] and not leak memory and use too much memory and make the device crash of course [/edit].

Again, for apps, different story. Please keep Flash out of Safari on iPhone.

michelleC Wrote: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.

SDL isn't "pretending" to be a compatibility layer, it is a compatibility layer. In what way do you mean it would it be "pretending"?

Comparing them is indeed like comparing apples to oranges, but what Apple is doing is to ban all kinds of vegetables because they found that rotten avocados are bad for you.

Skorche Wrote:I'm pretty sure that they don't want any cross platform UI libraries regardless of what language they are written in. If somebody decided for some reason to make an iPhone version of GTK or WxWidgets, I'd imagine that to be in the same boat. Cross platform "compatibility layers" are bad in Apple's book because they allow you to make non-standard UIs. Forget the fact that you can trivially make a bad or non-standard UI using Cocoa Touch. There are plenty out there and Apple doesn't seem to care about banning those apps. While SDL is going to contribute much less to the user experience than a UI library, who cares as long as the finished product is functional and usable.

This makes no sense; Would Apple accept ugly apps as long as they are written in ObjC with no third-party stuff, but reject apps that look and behave well just because they use some intermediary layer? It just can't be possible. But indeed that is what the paragraph says.

Quote:And as for Xcode... Most people around here really dislike it. Since starting iPhone dev, I've grown to hate it even more as it tries to do all sorts of extra magic for me. When something goes wrong with a project's build settings it can make it really difficult to fix.

I have spent quite some time making a replacement, and for my needs (and some others'), it is already more than usable. And a big thing is exactly what you say: there is too much magic going on in Xcode's project settings, it is too easy to get lost. YMMV, but for me is makes a big difference. And such a tool is for us who feel that way. I have considered strengthening the ObjC support, and if possible make it upload to iPhone (legally, using whatever authentication Apple wants me to), but now I don't know if that is at all worthwhile.

Ingemar Wrote:This makes no sense; Would Apple accept ugly apps as long as they are written in ObjC with no third-party stuff, but reject apps that look and behave well just because they use some intermediary layer? It just can't be possible. But indeed that is what the paragraph says.

But they do accept apps with terrible UIs written in Objective-C and using CocoaTouch. They accept ones that crash constantly too. From what Apple has said, I imagine that they will automatically reject an app written in Flash when the executable is detected to have Adobe libraries in it. They already have some automated stuff in place to prevent you from using private APIs. Presumably it just works by looking for certain symbols or something. It would be easy enough to just add symbols for Mono, Flash, or any other library that they decide that they don't like on their platform.

Skorche Wrote:They accept ones that crash constantly too. From what Apple has said, I imagine that they will automatically reject an app written in Flash when the executable is detected to have Adobe libraries in it. They already have some automated stuff in place to prevent you from using private APIs. Presumably it just works by looking for certain symbols or something. It would be easy enough to just add symbols for Mono, Flash, or any other library that they decide that they don't like on their platform.

If that's the case, then I wonder if you could just get around that by stripping debugging symbols. Assuming you statically link the libraries anyway, that should strip away most evidence. Although, I guess the implementers of the compatibility layer will have to be careful to implement as little as possible in Objective C, since I'm sure it needs to keep the message names around for its messaging system, and they would also have to be careful about string constants in general. It might even work with interpreted code, such as C#, if you store the bytecode as a byte array compiled in C and passing that directly to the interpreter. Having stripped symbols also has a valid excuse that it saves space, which is important for an embedded system.

As for existing titles, I know that there have been a lot of games released that are emulated games from older systems, such as older consoles and the Commodore 64. They were allowed before since they could only run the games they were shipped with, as opposed to arbitrary ROM images, but since it's going through an emulator that part can't save them anymore. Will those be retroactively rejected, or simply not allowed anymore? There's no real alternative for these games, either, since re-writing them from scratch would take much more effort and almost certainly won't get everything the same as the original.

I have a friend who is making a game for the iPhone, and he was thinking about using Unity for his game. This recent news has his plans in doubt, as well as farther reaching questions about what is and isn't acceptable. My friends who have an iPhone really have a love-hate relationship due to the restrictions in place. It'll be interesting to see how this slap in the face plays out with developers, and see how many try to stand up to this or if they'll just keep taking the continually worse abuse that Apple is doling out.

That's a great article on this whole situation. Read the "WHY DOESN'T APPLE LIKE 3RD PARTY RUNTIME ENVIRONMENTS?" section to see why Apple did this. Apple isn't going to let another company dictate to them about app development. Period. End of story.

Yes, I read the DevWhy article and found it unconvincing. If the framework is using the same public APIs that the individual developers use, and presents a good user experience, what's the difference?

Well there are some differences, but they are mostly positive. Developers use tools like these for a reason. They reduce bugs, and centralize the task of updating code in response to hardware and API changes. The "downside" is that Apple has one large company yelling at them instead of thousands of individual developers. Is that somehow going to allow Adobe to dictate terms? Seems a bit vague to me.

Quote:Of course, why any developer would want to use some third-party go-between dev tool like Flash or Unity in the first place is beyond me.

Done properly it saves time and money, and allows better games to be put out for multiple platforms in a fraction of the time.

One example of this is the casual market. The most successful companies are the ones that put their games out for multiple platforms quickly. They put them on browsers, Mac, PC, and multiple mobile platforms, and they do it by hiding the hardware from the game logic. Sometimes they do it natively, sometimes with a scripting language. They don't do it by writing game logic in Cocoa.

Don't like casual games? Read the postmortems for AAA titles in Gamasutra. Typically levels are designed, game events are scripted. Companies used to write their own scripting languages but its more common now that they use something like Python or Lua. They get a more powerful language than a homegrown one, cheaply. Look at Civ IV. Heavily moddable, thanks to extensive use of Python.

Heck, read the postmortem for Kiki the Nanobot, uDevGames winner back in 2002 or so.

In fact one reason I use Unity is precisely because they are an intermediary between my game and Apple's whims. I don't mind if Apple changes something drastically, or even something subtle with a graphics driver for one particular video card, because I've outsourced that work. It's ironic that Apple wants to take that layer away from me in order to make my apps more reliable. Apple either doesn't have any idea how modern games are written, or doesn't care.