Its starting to look like, once again, they have managed to screw up and miss the boat...

I think they already did. As soon as D3D12 preview came out it took the boat and the pier with it.

Thats a harsh reaction to making an API available on more platforms then it was before... what do you suggest they do?

Well I would be happy it if they would opensource the whole api etc.. Downloading/installing Mac like Ubuntu on my chosen hardware and not

the other way round.

You know what? I get so sick and tired of hearing people say this. Apple is not required to open source anything, just like Microsoft doesn't have to open source DirectX. Nobody complains about an API being Windows only, but God forbid an API is Mac only. Good grief...

I think Apple is using Metal and these other Objective C frameworks, like spritekit, scenekit as a trojan horse to trick developers into locking in their games to Apple platforms. It's only later on the developer releases that they can make a lot of money on other platforms, but they don't have to resources to re-write the game.

This doesn't make any sense to me. For starters, most reasonably written engines support multiple rendering backends, so if a specific API is not supported, then it can fallback to a different one by default. This is what BB Racing for iOS does. Second, your game shouldn't be so poorly written that it depends on one API. If you have to rewrite a game because of the renderer, then that's a sign of poor planning and/or lack of experience on the devs part. This isn't rocket science, id and Epic have been doing this for years.

Shogun.

...just like Microsoft doesn't have to open source DirectX. Nobody complains about an API being Windows only...

Oh yeah they do

...just like Microsoft doesn't have to open source DirectX. Nobody complains about an API being Windows only...

Oh yeah they do

Not nearly as much as when Apple does it! :)

Shogun

... but your logic is all wrong. Even if Android makes less than iOS, a game on Android *and* iOS makes more than just iOS

I think you'll find your logic is a bit wonky here.

You've already said Apple give you a bunch of libs to work with, add to that a lower number of device and OS combinations to target you've got a relatively easy target area to hit to get your game out.

Android development, however, is a clusterfuck of bullshit and hate and generally takes more effort than the iOS version and for less return. Maybe it's a little better if you stay in Java land but if you are complaining about Apple's stuff then its logical to assume your theoretical developer is using C++ to at least cross platform as much as possible, at which point... ahahahahahahahaha.

So unless you are CERTAIN your Android version will make back the extra to cover the costs of development it might not be worth it. Higher revenue doesn't always equal higher profit after all.

However, as noted, mobile is a death march with most games and apps making basically nothing and certainly not enough to survive on, so even if you target both unless you've got a killer app AND you get lucky then you are unlikely to make any money regardless of where you publish your stuff.

I think the wonky logic is presenting opinion as fact, as so often happens when Apple is involved. I've got nothing against a company making their own API, but Android development is just fine in my opinion (I've done C++ as well as Java), for starters it can be done without only owning Apple hardware. IOS now has more than enough different devices with capabilities, sizes, aspect ratios, resolutions that the "only one device to target" benefit is _long_ gone; there are also still different OS versions (old devices just get labelled with an OS that has the latest version number, even if it doesn't have all the functionality of the real latest OS). (Perhaps people on Android can't spend as much, because things are only released for the minority of iphone users.)

Of course there are pros and cons to each platform, but with it hard to make money on mobile, that works in reverse too (is it worth the cost to port something to IOS, unless you are CERTAIN). As a consumer it's a good thing when prices are lower.

Though for people using game engines, my understanding these are mainly cross-platform already, and they can add support for all available APIs, making this a non-issue, and the debate about which platform to support is off-topic to this.

More generally though on API politics, I note how for years we've heard that one must support OpenGL because "MS is evil", "cross-platform is good in principal", "we can't possibly forget that 3% of Mac users". So it is not unsuprising that Apple get some of that flak that, especially when that 3% of Mac users is now a billion or more active Android devices. I remember fears of the death of OpenGL years ago with the disappointment over Longs Peak.

Maybe things are worse now for OpenGL on PC platforms, but it's not like the Mac 3% gaming share was huge in the first place.

"Nobody complains about an API being Windows only"

Did you manage to miss 10-15 years of DirectX vs OpenGL flamewars? :) It's hard to quantify who gets more criticism, but it's not uncommon to see people criticising Windows for being Microsoft, evil, anti-competitive etc - and then you find out they're an Apple users. Or how we get an uproar because something doesn't support the single digit percentage of Mac users, but only supporting the minority Apple phone users and ignoring Android is fair game (this most commonly happens with free applications for a website or service, so the revenue argument doesn't apply) - and heaven forbid someone should support the single digit percentage of WP users.

but Android development is just fine in my opinion (I've done C++ as well as Java), for starters it can be done without only owning Apple hardware. IOS now has more than enough different devices with capabilities, sizes, aspect ratios, resolutions that the "only one device to target" benefit is _long_ gone; there are also still different OS versions (old devices just get labelled with an OS that has the latest version number, even if it doesn't have all the functionality of the real latest OS). (Perhaps people on Android can't spend as much, because things are only released for the minority of iphone users.)

Firstly, I avoided the 'one device', I said 'smaller target area' and I said it on purpose because while it isn't one device you've got a much smaller place to hit.

As for your experience; lucky you.

I'll tell you my experience of the last 18 months.
- The tooling is shit.
- The docs are shit.
- The OS is shit.

Do you have a sane debugger? Nope... there is some console based abortion like we are still in the fucking 90s, or there are the plugins which have a wonderful tendency to 'step in to..' and never return. It is MORE hastle to use a debugger than do round trips with log output. (Which is full of bullshit too as everything vomits into it.)

Gotchas are utterly undocumented and vary between device running the same version of the OS.
Where do you push an OBB file to test it? Good luck working that out because 4.2 lets you put it in one place, but 4.4 introduced multiple user support (on a fucking minor revision? are you shitting me?) which now changes file permissions and write permissions so you end up having to query the device version to try and push. BUT WAIT! THERE IS MORE! Some devices won't warn you the initial old way no longer works, you adb push and it pretends like all was ok, some times on some devices you can physically SEE the file - does it want to access it when you run the app? Does it fuck. - in other cases the file you pushed just vanishes. It goes away into the ether. Of course on some other devices once you've figured out you are on a 4.4 or above device it doesn't matter; you can push the right place but file permissions remain so fucked you cant access it anyway.

All, fyi, undocumented.

Across devices there are broken drivers, incorrectly implemented specs and other problems where physically identical hardware has different rendering errors present requiring different work arounds.

The control panel for the store is laughably broken; got an apk with an obb you want to upload? Good luck with that as you'll be uploading the apk twice just to get the option to upload the obb file. Broken for over two years fyi. Sometimes you'll upload a new version of the apk and you wont even get the option to associate with an apk meaning that you have to upload it AGAIN. (A Test app required 5 uploads for 3 revisions.. I mean, they are a fucking web company!).

And don't even get me started on the 'must be in a community to alpha/beta test' bullshit.. I mean, wtf? Remove the ability to test from draft and then require more fucking hoop jumping to test? Christ...

Other things just straight out lack examples (invoke a custom activity and get a result back...) or are undocumented (hitting 'back' from a custom activity will ALWAYS return cancelled, even if you intercept the closure and try to say it is ok) or just down right insane.

While I've not done iOS development from those who have done both I've heard it is much better and at least you have tools that are useful.
Android is, by far, the worst development environment I've had the displeasure of using, so much so that I've stopped using all my Android devices at home and have gone fully Windows based with no intention of touching that god forsaken mess of an OS ever again as a consumer.

So, yes, Android DOES require far more effort than iOS which does directly impact ROI and income.
These are facts.

Vulkan has no spec, no beta and no release date

That's it, sadly.

All I've seen so far are sales pitch kind of powerpoint slides.

As in, we decided for a name, and we have a bag full of ideas, and it will be the greatest MMORPG of all times -- basically like WoW, but you can can like... craft, and kill stuff, and have open, unlimited PvP and there are no health bars, and .... Oh, wait a moment. I mean, it will be the greatest graphics API of all times, basically like Mantle, except it's better and have its own shader language bytecode and will run on every whatsoever-heterogenous hardware and be so much faster and more flexible. No, we don't have anything concrete yet, sorry.

Give me a spec and a beta driver, and I'll be happy to use it even though I'm not convinced that throwing everything overboad and doing everything low level is a good design decision.

You know, some stuff in OpenGL isn't that bad at all. Not having to do every low level task yourself like in the 1980s can be a good thing. For example, I'd be perfectly happy telling OpenGL where I want a buffer preferrably stored (but in a way that works better and is less opaque than the current usage flags), and not not having to care about doing DMA transfers manually. It's not just way more user-friendly, but it's also something that the majority of people will get wrong half of the time, too, if they have to do it themselves. Add to that persistent mappings, make everything DSA (throw all non-DSA stuff over board, and scratch all the useless validation stuff... like who cares if a framebuffer is complete, you'll surely notice that something is wrong if half of your render targets are black), allow having several command queues, and there we go. That's not the "perfect" API, but it's one that you can write a spec for in a week or so (rather than... years), and it's one that driver writers can incorporate in a week as well (based on what they already have), and it will work. People will be able to use it without much hassle, and it will be reasonably efficient.

Who cares if "Vulkan" is 0.2% faster on the average for the average project (and maybe 100% faster in contrieved special examples) if it's factually not available for years to come, if you have to write 3x the number of lines of code, and if 20% of the programmers will manage to crash the display driver at inopportune times.

One thing to keep in mind about technologies like Metal is that they are "close to the metal" (pun intended of course), which provides options for finding common ground at a slightly-higher abstraction layer.

For example, MetalGL provides a bridge to the improved performance available from Metal, while retaining API compatibility with the open cross-platform standard of OpenGL. The result is the common compatibility abstraction layer mentioned above, available at a layer lower than the game or app (i.e.- let the driver provide the cross-platform abstraction, not the app).

So, with the introduction of Metal, Apple is actually enabling the improvement of all common API's, including OpenGL (and Vulkan in the future), given the right driver development.