22 replies to this topic

[nagromme]

Let’s hope it’s poor wording or else a blunder Apple simply reverses (as has happened before). This sounds scary:

http://daringfirebal..._flash_compiler

His conclusions are guesswork, but they sound reasonable. If this is what it looks like, it doesn’t hurt Adobe nearly as much as it hurts small, innovative indie developers. I just paid my $99 to Apple this week... and now my Unity-based game (which playtesters have really liked) may never see the light. I have sunk a LOT of time and money into it, too. As have the developers of some great existing iPhone games, some of which Apple has themselves featured! Gameloft can hire a team and throw a million dollars at a new game with the marketing to make sure it sells. The little guy NEEDS tools like Unity or certain games will just never be seen. A shame.

It seems this clause wouldn’t just ban Flash, but also Unity and Torque (and many tools I’ve never even heard of). And I wonder if some big-name engines and game ports (emulators, Id remakes, Unreal Engine) involve a middle layer that would be banned by this too. Even Netflix and the supposed upcoming Hulu app, maybe.

And if true, what about future updates to games already out? I can’t imagine Apple pulling existing games (OK, I can) but having a game that never gets updated for future OS/hardware versions makes no sense either.

[ltcommander.data]

nagromme, on 08 April 2010 - 07:25 PM, said:

And I wonder if some big-name engines and game ports (emulators, Id remakes, Unreal Engine) involve a middle layer that would be banned by this too. Even Netflix and the supposed upcoming Hulu app, maybe.

http://www.pocketgam...ngine 3 (iPhone)/news.asp?c=19009

Quote

Another key reason is that Unreal Script - which makes up the bulk of the gameplay logic of Unreal games works unmodified on iPhone. This only happens thanks to the very close cooperation between Epic and Apple that enables its virtual machine to be supported on iPhone; a technical feature that no other game developer is allowed due to security restrictions.

It does have the potential to ban Unreal Engine due to UnrealScript. However, interestingly Apple reportedly specifically worked with Epic to implement the virtual machine necessary to run UnrealScript on the iPhone since otherwise the VM would have been banned. If Epic has an exception on running VMs they could probably get an exception for the UnrealScript language that runs on top of that VM. Of course this does bring up questions about consistency of rules and who gets exceptions. I wouldn't be surprised either if it turns out Apple has now changed it's mind and revoked Epic's VM privileges despite all the work they put in together.

[Janichsan]

TUAW got in contact with Unity Technologies and it seems, they are not affected by the change of the license agreement. At least that is what Unity heard from Apple so far.

[nagromme]

That’s a good sign, but the direct quote doesn’t make me feel sure Unity Technologies has a solid answer yet:

Helgason says that so far Unity has "no indication from Apple that things are going to change.”

That could just mean Apple never contacted Unity to give them the boot. It doesn’t necessarily mean Unity has yet gotten a response from Apple.

Make that statement a little less vague, and although nothing is ever REALLY certain, I’ll be a lot happier!

(Another side to this story: there’s a reason people are so nervous. Apple’s behavior with the App Store has been ham-fisted in the past. They are now dealing with a reputation that they earned.)

[Eric5h5]

I don't buy the "cross-platform" theory; doesn't make any sense.  Apply is perfectly happy to feature well-known games that get ported to the iDevices (GTA, Civ Rev, Need for Speed, etc.).  No matter whether they are ported to or from the iPhone, they still exist on other systems.  Or is Apple going to insist that all games be unique to the iPhone and can't exist elsewhere, and start refusing to allow big-name companies to port their IP over?  They're not that insane.  In the absence of any hard info, it's all just speculation.  I'm still going with "heavy-handed attempt to ban CS5 Flash exporting without actually mentioning Adobe by name".

--Eric

[Janichsan]

I don't think with "cross platform" they mean apps that are also available on other platforms per se. That Flash compiler is a perfect example of what they are trying to prevent: an app gets slapped together with a certain tool and with one click of a button you get the same app in some kind of wrapper for half a dozen different platforms, without having been actually developed with taking the special features of each platform into account. When an app is actually ported (in the sense of being more or less hand-coded) it's usually better adapted to the platform it's being ported to, e.g. tweaks in the user-interface.

But yes, I agree: I believe the whole move is basically to prevent Flash in any form on the iPhone. Especially when you consider that the first sentence of section 3.3.1 ("Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs.") could in very strict sense even apply to stuff like SDL – which is so wide spread that I cannot believe that Apple would chuck out any app using it.

[NAG]

Appleinsider is saying something about how they think it is due to multitasking not working as well.

I think the not wanting wrapped shovelware sounds like the most likely reason though.

[Eric5h5]

Janichsan, on 10 April 2010 - 02:17 AM, said:

Especially when you consider that the first sentence of section 3.3.1 ("Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs.") could in very strict sense even apply to stuff like SDL – which is so wide spread that I cannot believe that Apple would chuck out any app using it.

That means private APIs as in Apple's APIs that are technically available and can be used, but not documented, and Apple doesn't want you to use them.  Which is reasonable, since undocumented APIs can change at any time and then your app breaks.  Although they still manage to do that sometimes even with public APIs....

NAG, on 10 April 2010 - 03:45 AM, said:

I think the not wanting wrapped shovelware sounds like the most likely reason though.

Not shovelware (they get plenty of that with standard apps and don't seem to object to it, since it pads out their app numbers) so much as getting around the Mac-only development toolchain requirement.

--Eric

[nagromme]

Eric5h5, on 10 April 2010 - 06:41 AM, said:

...
Not shovelware (they get plenty of that with standard apps and don't seem to object to it, since it pads out their app numbers) so much as getting around the Mac-only development toolchain requirement.

--Eric

Actually, they did a huge shovelware purge—not just “adult” apps, but “business card apps” a.k.a. “apps with limited functionality.” That’s some serious shovelware. (Like an app which just displays your company’s home page or logo with an email button. Things that are better done via web app than cluttering up the App Store).

Mac-only makes sense, except if it was ONLY that, then they could have said that in a simpler way that didn’t get into “original languages” and other things. They could have said “must be compiled using Xcode” and left it at that.

[teflon]

Isn't it more like Cider vs Traditional ports of an app?
Cider apps are often considered to be a bit hinky and strange and poor performing compared to traditional ports, which can often add more Mac like functionality and features.

I did see an opinion piece related to this that flash apps (or whatever) that have been converted wont be able to tie into the multitasking APIs as well as a native app, and slow the whole system right down. Don't forget, it's not true multitasking, anyway..

[DaveyJJ]

I, too, have now heard from a number of sources that Unity will be fine. Nothing yet 100% certain, but people I've been speaking with (some off record) have indicated things are all OK on the Unity front. Whew.

[nagromme]

Any words of comfort are welcome, DaveyJJ

teflon, on 10 April 2010 - 12:18 PM, said:

Isn't it more like Cider vs Traditional ports of an app?
Cider apps are often considered to be a bit hinky and strange and poor performing compared to traditional ports, which can often add more Mac like functionality and features.

I did see an opinion piece related to this that flash apps (or whatever) that have been converted wont be able to tie into the multitasking APIs as well as a native app, and slow the whole system right down. Don't forget, it's not true multitasking, anyway..

I think Flash (but not Unity) may be more like Cider, in that there’s a Flash file wrapped in something else that translates it (Flash player app).

The multitasking issue sounds like just speculation to me, but a reasonable enough theory. Re slowing the whole system down, though—I don’t think any apps would do that. Otherwise TONS of existing apps would so so (ones which are pure Xcode but simply haven’t been rewritten for the new APIs, and in many cases will never be). Rather, I think these old “non-multitasking-ready” apps would simply not offer the best experience of their own functionality. They might just exit rather than properly “pause,” and thus would miss out on the fast-relaunch benefits. They’d work a lot like they do now, I assume.


P.S. as for not being “true” multitasking: that’s a good thing. Classic “true” multitasking (1900s-style power-gobbling brute-force multitasking, suitable for full-scale WIMP systems) would mean apps WOULD slow each other down. This is a more efficient solution—which is what mobile computing calls for. There’s no free lunch in the battle between battery vs. performance vs. portability. But this solution sounds like a good one! To the user, it will act like true multitasking nearly all the time—but without the big drawbacks.

I’m imagining if computers all had one processor per task, and we were using hulking heaters that could multitask 20 apps because they had 20 cores (even if each were barely used most of the time). And then if someone came along and made a computer that could multitask on one or two processors (like they do in reality), the tech pundits would scream, "it doesn’t have true multitasking! Apps are forced to share processors! It’s a lame cop-out!" But in practice, it’s a great, efficient solution that draws less power and makes things smaller and cheaper.

And evidently (according to DaringFireball and others) Android uses a similar “pausing plus background services” system already. It’s not “true” multitasking either. Which makes me wonder—why does the Droid (and others) suffer from some of the same problems as true multitasking? Anyone have any insight? My friend doesn’t run all that many apps on her Droid, yet they were burning so much battery power than the phone was practically unable to even charge. She’d leave it overnight and it still wouldn’t be charged—and that’s with the screen off and the apps supposedly dormant. So the store she got it from recommended she get a task manager app, which I’ve seen many places is highly recommend for Android users. And now she has to deal with that manually, and the thing is STILL slow. What gives? Is it simply a badly-done rush implementation of what Apple’s working to do right the first time?

My only theory right now: does Android allow apps to choose “true” multitasking and lose the benefits of the modern solution? (If that’s an option, I’m sure plenty of lazy developers would go that route.)

Just curious, in an O/T kinda way

[teflon]

Not sure about Droid.. I don't think it offers as neat and clearly defined a set of rules to go by, and it doesn't have set background APIs for the app to tie into. So it's not as neat a solution...

[Eric5h5]

teflon, on 10 April 2010 - 12:18 PM, said:

Isn't it more like Cider vs Traditional ports of an app?

No, at least not in the case of Unity.  Cider is taking a Windows app and running it essentially unmodified through a translation layer.  The success of that depends on how well they manage to reverse-engineer Windows.  Unity on the other hand is completely native code, and uses iPhone-specific features.  In fact the ideal workflow is quite iPhone-dependent, since they made a small app for Unity that essentially turns the device into a remote control, so you can test your stuff using actual multi-touch/accelerometer input instantly, without having to compile anything.  (And any OS features it doesn't support out of the box can be added by programming in XCode.)

Also, I don't think I buy the multitasking thing.

nagromme, on 10 April 2010 - 11:23 AM, said:

Actually, they did a huge shovelware purge

Indeed they did, plus that Khalid guy a while ago who had something like 1000 spam (and IP-infringing) apps.  However that hasn't really stopped the flood of shovelware; if you watch the releases it's not uncommon to see people releasing the same app a dozen times with nothing more than different backgrounds, and that sort of thing.

--Eric

[teflon]

Sorry, I don't think I was quite clear. Unity is the equivalent of a native port of the Doom 3 Engine to the Mac, whilst Flash is the equivalent of Cider. One works directly with the OS, the other goes through an emulation layer.
Apple's new policy is just to get rid of the Cider-esque stuff which won't work quite as smoothly. So if something is going into native code, then it'll be fine. This means that Unreal Engine 3 (which is modular, hence how a lot of it is unchanged across all platforms) or Unity or whatever is safe. Flash in a translation layer isn't safe.

[Eric5h5]

Ah, OK.  At any rate, it's definitely not about multitasking, since I've just learned that Unity works fine with the multitasking (or rather app-switching) in 4.0.  Apparently apps built with anything earlier do not work properly with app-switching.

--Eric

[NAG]

I didn't say the shovelware reason was good. I just think it is more likely than the multitasking reason Appleinsider was throwing around. Anyway, Engadget is saying that Steve Jobs is saying this is an insightful post. So the reasoning is probably somewhere along those lines.

[nagromme]

NAG, on 10 April 2010 - 08:26 PM, said:

I didn't say the shovelware reason was good. I just think it is more likely than the multitasking reason Appleinsider was throwing around. Anyway, Engadget is saying that Steve Jobs is saying this is an insightful post. So the reasoning is probably somewhere along those lines.

Gruber’s analysis sounds better to me than AppleInsider’s “sources” (who could be good ones but there’s no reason to think so). I think, though, that games needed to be considered differently from other app development. Performance matters more, while UI matters less! Hopefully Apple’t thinking, if Gruber’s right about their fears, doesn’t apply to Unity. Still—I do fear that they might consider Unity acceptable collateral damage! But minds can be changed, and Apple has shown flexibility on things like this. One thing I’ll say about Apple’s various App Store blunders: they don’t stick to their guns from pure ego or the desire to look strong. They do a 180 sometimes when it’s called for. (I don’t expect that re Flash, but if Unity and other tools turn out to be caught up in this, that could change.)

[Omaha Sternberg]

I've had the opportunity to speak with the folks from Unity, Torque, and GameSalad, and as of yesterday, none of them had spoken directly to Apple. They all expressed that Apple had not spoken to them and had given no indication that they were in the wrong, breaching any contract, etc. Which is not to say that Apple won't in the future. But each believed that their product was probably in the clear, and even if not was flexible enough that it could be changed to quickly accommodate what Apple required.

What really bothers me is that this is not the only lock-down that is in the agreement. Another one has just been revealed about third party software measuring data:

"...the use of third party software in Your Application to collect and send Device Data to a third party for processing or analysis is expressly prohibited."

Some are seeing that as saying goodbye to every ad analysis and advertising company that works with the iPhone/iPod Touch at this time. I can't imagine that it doesn't impact every single social networking leaderboard company either, like Plus+, Scoreloop, and OpenFeint. I mean, aren't those classified as third-party software sending data from your device that is then processed and analyzed?

Omaha

[nagromme]

Apple may LIKE things vague. More power/flexibility for them, and let those affected (the tool developers like Unity) figure it all out for themselves and hope for the best. (Maybe I’m too pessimistic.) However, Unity’s folks posted that they have meetings lined up with Apple soon (maybe even already). So, better clarification is on the way.

Omaha Sternberg, on 13 April 2010 - 01:01 PM, said:

"...the use of third party software in Your Application to collect and send Device Data to a third party for processing or analysis is expressly prohibited.”

I’m no rodeo clown, but I would think they key phrase there is “Device Data.” Data about your device. Obviously Apple’s not going to ban the sending of all 2-way communication from apps. But device data sounds to me like collecting the capacity of your phone, how many photos are in your library, how recent the model is, what your free RAM is, etc. Some of which is personal info, others of which Apple may feel is spying on their inner workings. Or maybe it’s JUST hardware specs. (Maybe so they can keep their competitors in the dark re models and market shares? Why help Microsoft decide how many GB of storage to put in the next Zune?)

In any case, I suspect ads are free to ASK you your age/sex (as some do), and they can even know your IP address to guess your general location, but they cannot transmit info on your hardware. This is all purely a guess.