Today's license changes and Unity

Moderator
Posts: 3,577
Joined: 2003.06
Post: #61
Well said!

MattDiamond Wrote:Apple either doesn't have any idea how modern games are written, or doesn't care.

Again, I don't think it's Apple as a whole, but rather the upper management, and specifically, Steve Jobs. And after all the discussion, I don't think it's that he doesn't know so much about how modern games are made, but really just doesn't care. There's no special categorization for games in his mind -- a game is just another app.

On the social gaming network thing, after thinking about this some more, I don't think he answered that question fully. I think there are at least three reasons they did it:
1) Microsoft is including it in Windows Phone 7, and they don't want it to be a point of comparison.
2) Even free games will be potential revenue generators for them through iAd, and social gaming will keep gamers' attention for longer.
3) Developers whined and complained about it. So instead of mentioning point 1 or 2 and appearing sleazy or weak, it's easier to just say #3 and move on to the next question. Again, best practice is to blame it on the developers. Ehem, did that sound snarky? I meant say that you did it because you *care* about what the developers asked for, and you're doing it out of the kindness of your heart.
Quote this message in a reply
Moderator
Posts: 3,577
Joined: 2003.06
Post: #62
OneSadCookie Wrote:http://arstechnica.com/staff/fatbits/201...-wager.ars agrees with that sentiment.

That is an amazingly accurate article in my opinion!
Quote this message in a reply
Member
Posts: 27
Joined: 2010.01
Post: #63
Ingemar Wrote: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.


Using SDL as a staticly compiled library that plays by all the rules will probably make it thru Apple's visual and automated audit checks.

Using it as one big monolithic library that takes over the whole runtime and doesn't have an ounce of hig is going to prompt further scrutiny and maybe rejection. If you have a develeoper account you could be in on a our very long thread on the apple site.

The act is clearly aimed at cross-compilers and compatibility layers that take complete control over the environment.

How can you develop automated tools to find these, you can't. You can look for particular symbols in object code And also have involve your qa testers, if by visible inspection something looks a bit odd you can start pouring into the source code.

As I explained to the sdl crowd long before this 3.3.2 change, any app that uses no HIG entirely is going to gain some reviewers attention. period. New or old guidelines.


I am sure sdl is a very good compatibility layer on windows, linux and whatever. but on the iphone it is just a huge classlib with a lot of potential. I've been trying to make it better conform to hig with some help and a lot of resistance from the sdl evangelist.

But I don;t consider it a compatibility layer if to get some simple overlays I have to recode much of the opengl handling, to get a simple splitsviewController to work I have to bring over locally and recode most of the initialization code. As I said a lot of unfinished potential. And the Project heads agree that the iphone implementation is very soft, and are actually greatfull and very supportive of developers who want to make it better. But compatibility layer on the iphone it is not and to use that terminology now could be fatal.

I really think a lot of the same arguments could be made for unity, dispite what others are saying I think you still can get unity apps that abide by the HIG on the iphone.

If the review process was that critical there wouldn't be all those apps that use the private core surface framework and get to the appstore.
Quote this message in a reply
Member
Posts: 260
Joined: 2005.05
Post: #64
michelleC Wrote:If the review process was that critical there wouldn't be all those apps that use the private core surface framework and get to the appstore.
My problem isn't how critical they are, but that they explicitly ban just about everything except the most trivial apps. Then they can let a lot of apps though that are really breaking the rules; they must or they won't get many in the AppStore. What I don't like is having to lie about my work, and having to live with the fear of Apple introducing some check that matches how I work and bans me from AppStore.
Quote this message in a reply
Member
Posts: 27
Joined: 2010.01
Post: #65
True,

But Apple can be very flexible too, and my guess is before 4.0 hits they will clarify this, again I think what they are trying to ban is true object level cross-compilers not things like unity.

Case in point, have you seen on of the latest iphone adds, the one where the user checks a price with a bar code reading apps.

Bar code reading apps are interesting, they are not hard to do but prior ot just a few months ago technically couldn't be sold through the appstore.

Almost all bar code readers use the method uigetscreenimage, that is a private method that lets you grap the image of the screen at any time. Its crucial for realtime analysis of camera data. But it is a private framework. Apple made special exception to allow that private function because they realized that augmented reality and bar code apps were essential to there demographic.

But the really good bar code readers use something called open computer vision or opencv which is a third part api, which is fine but they are usually used with core surface an api that Apple currently does not allow, but probably will soon.
Our app has an on device mpeg2 decoder, we made some inquries and got mixed replies from Apple about not being able to run on 3g because we don't comply with streaming standards, but they made special mention of the fact that wifi only standards ARE DIFFERENT than 3g.

Maybe the market is just too new, and to fluid and everyone's a little worried that the "other Player" is going to get an edge on their game.

is there really a possibility that actionscript or c# could gain ground on the iphone, I don't think so but maybe some analyst at apple does...

I think its more fear than conspiracy or domination .
Quote this message in a reply
Sage
Posts: 1,482
Joined: 2002.09
Post: #66
Anybody read this? Unity CEO Promises ‘Uninterrupted Service’ in Wake of iPhone OS 4.0 TOS Change It's a bit scant on details or references though.

Scott Lembcke - Howling Moon Software
Author of Chipmunk Physics - A fast and simple rigid body physics library in C.
Quote this message in a reply
Moderator
Posts: 3,577
Joined: 2003.06
Post: #67
See? I told you so Rasp ... of course we need to see what actually happens, but my wager still stands!
Quote this message in a reply
Member
Posts: 269
Joined: 2005.04
Post: #68
http://iansamuel.com/essays/progress-of-the-platform/

Quote:The simple effect of the new SDK is to announce, loud and clear, that developers who want to write iPhone and iPad software have to do it the iPhone and iPad way. You are supposed to use Xcode and Objective C and Webkit, just like Apple does. You are supposed to use Cocoa Touch and borrow the user interface metaphors that Apple has helpfully illustrated in their own apps. If you do anything else, Apple is going to try and stop you. That means no cross-compiling other languages; no cross-platform frameworks like Qt; nothing. Stop trying to get out of writing real iPhone apps, Apple seems to be saying.

To people who think of such things in a technical fashion, this is offensive: Why shouldn’t I be able to use whatever language and whatever tools that I want to write an app? And indeed, there is no technical argument for this at all. As long as an app isn’t linking to private APIs, and is going through the same App Store approval process as every other app, there is no technical reason that it shouldn’t be able to be written in ActionScript or based on Qt or whatever. If it provides a horrible user experience, well, let the market decide.

But the reason isn’t technical. It’s partly business (Apple doesn’t want another company to control any important part of the iPhone platform), but it’s also in no small part grounded in aesthetics and the progress of the platform. Apple wants developers to do things the iPhone and iPad Way because they believe it will result in a better user experience and better designed apps. That’s an aesthetic, design-centered argument about how touch apps should be done. Apple has created tools customized to the iPhone and iPad; hell, they built a whole new touch-based operating system. They created a whole set of user interface metaphors that are supposed to be standard and system-wide, and they want developers to do things the new way not because Apple just loves power, but because they believe it’s necessary to force developers to think about the new world of touch-based computing correctly. All of this in service of giving users who are taking their first steps into touch-based computing a great experience.

Double emphasis:

Quote:Stop trying to get out of writing real iPhone apps, Apple seems to be saying.
Quote this message in a reply
Sage
Posts: 1,482
Joined: 2002.09
Post: #69
Again, the problem is that for many apps, and a fair percentage of the popular ones is that the functionality they provide is so basic and simple that no guidelines are needed. To make a polished farting application, do you really need to use Cocoa at all? All you need is a button that says "press here to fart".

Example:

Most developer's productivity would also benefit from a modern runtime that provides what are now considered to be basic tools like garbage collection. 90% of the apps on the app store don't have such strict memory usage requirements where they are better off using reference counting. A lot of apps already leak like a sieve anyway. Garbage collection would only serve to improve the overall software quality on the iPhone with a trivial performance impact. Apple in their infinite wisdom has decided that you shouldn't have access to the Objective-C garbage collector instead. I can only presume that this is to encourage tighter resource usage, but again I think that this only backfires on them. Good developers know how to use memory efficiently with or without a garbage collector. So it's not like it would bring down the quality of best apps, and would at worst improve the mediocre apps. For most uses, implementing manual memory management is a huge waste of time for the percent or two of runtime efficiency that you get from it in the average case.

Scott Lembcke - Howling Moon Software
Author of Chipmunk Physics - A fast and simple rigid body physics library in C.
Quote this message in a reply
Moderator
Posts: 1,140
Joined: 2005.07
Post: #70
Bachus Wrote:Double emphasis:
Quote:Stop trying to get out of writing real iPhone apps, Apple seems to be saying.
This would be much better served by enforcing interface guidelines. Oftentimes you don't need the full power of the the interface library, you only need a small subset to get what you need. If a 3rd party library gets you that subset and lays it out in a compliant way with less effort, why not? If you're making a game, you usually aren't using the provided interface elements either. Blanket policies like "you cannot use anything other than our APIs" misses both the people who use other tools that make compliant interfaces and those who use the "correct" tools but make crappy interfaces. If they instead enforce interface guidelines, then you filter out what will truly hurt the user experience: crappy interfaces. Otherwise they are just doing it for the control.

Skorche Wrote:Most developer's productivity would also benefit from a modern runtime that provides what are now considered to be basic tools like garbage collection. 90% of the apps on the app store don't have such strict memory usage requirements where they are better off using reference counting. A lot of apps already leak like a sieve anyway. Garbage collection would only serve to improve the overall software quality on the iPhone with a trivial performance impact. Apple in their infinite wisdom has decided that you shouldn't have access to the Objective-C garbage collector instead. I can only presume that this is to encourage tighter resource usage, but again I think that this only backfires on them. Good developers know how to use memory efficiently with or without a garbage collector. So it's not like it would bring down the quality of best apps, and would at worst improve the mediocre apps. For most uses, implementing manual memory management is a huge waste of time for the percent or two of runtime efficiency that you get from it in the average case.
IIRC, the ObjectiveC 2.0 garbage collector is optional. If they merely have it enabled by default (and ship it with the OS), then it covers the best of both worlds: those who can't manage their memory won't crash once you hit the fart button 10 times, while those who can manage their memory don't need to take the hit of a garbage collector.
Quote this message in a reply
Moderator
Posts: 435
Joined: 2002.09
Post: #71
Skorche Wrote:Anybody read this? Unity CEO Promises ‘Uninterrupted Service’ in Wake of iPhone OS 4.0 TOS Change It's a bit scant on details or references though.

It's basically quoting Helgason from the Unity blog.

I say "quoting" but it borders on misquoting. The actual quote is that Unity Technologies would LIKE to supply uninterrupted service, and is doing their best. The headline and the first sentence of the article are therefore misleading.

David Helgason's original language was very precise- Unity is doing their best to deliver, there are reasons to be optimistic, and the company is invested in finding a solution, including jumping through technical hoops if need be. He does not promise uninterrupted service; he knows he can't.

Sloppy articles piss me off. :-)

I believe that there is still a pretty good chance that we'll still be able to use Unity for iPhone eventually. But it's very much up in the air.

Helgason posted recently that they are meeting with Apple next week. So hopefully we'll know more after that.

Measure twice, cut once, curse three or four times.
Quote this message in a reply
Sage
Posts: 1,482
Joined: 2002.09
Post: #72
akb825 Wrote:IIRC, the ObjectiveC 2.0 garbage collector is optional. If they merely have it enabled by default (and ship it with the OS), then it covers the best of both worlds: those who can't manage their memory won't crash once you hit the fart button 10 times, while those who can manage their memory don't need to take the hit of a garbage collector.

You can use all the features you want of Objective-C 2.0 except the garbage collector on the iPhone. It's not even an option unless that has changed recently. I mean the iPhone stuff is already mostly done in a language with dynamic messaging. Not a huge performance hit, but it is a hit. If you were a really good developer, you would just write your app in assembly. Why bother with function call over heads? Taking away modern time saving features like garbage collection for no good reason is bizarre to me.

Scott Lembcke - Howling Moon Software
Author of Chipmunk Physics - A fast and simple rigid body physics library in C.
Quote this message in a reply
Member
Posts: 446
Joined: 2002.09
Post: #73
Skorche Wrote:...Not a huge performance hit, but it is a hit.
I'm confused as to why they left out the garbage collector as well. For what it's worth, Apple seems to be of the opinion that it would be a significant performance hit - their tech talks even strongly discourage the use of autorelease. Makes me wonder why they force feed us Objective-C at all...
Quote this message in a reply
Sage
Posts: 1,482
Joined: 2002.09
Post: #74
Exactly my thoughts. If the point was to force developers to make super-well tuned code, then why encourage them to use a language with relatively slow method invocations? It makes no real sense.

So memory is tighter on the iPhone too, but my old G3 iMac with 256MB of RAM ran just fine with a much bigger screen and several things running at the same time. IMO, by making people use a garbage collector by default would only make the memory situation better by preventing leaky applications from bringing themselves down. Sure you would still need to let go of cached data when you get a low memory warning, but it could also for a GC cycle at the same time to prevent leaks.

Scott Lembcke - Howling Moon Software
Author of Chipmunk Physics - A fast and simple rigid body physics library in C.
Quote this message in a reply
Post Reply