Next-Gen iPhone & iPhone Nano Speculation

Really low-end games wouldn't see any benefit anyway 98% of the time, since the stuff they draw is so primitive. So it matters little, really. It's the heavy stuff that will see benefits - although I still don't quite understand who exactly plays graphics-heavy games on a touchscreen device, and why. ;)
 
Even for low-end games there's still a benefit: since the API has little overhead, it's using less CPU and thus less power wasted which means more battery time.

And I guess that a lot of these games use Unity so would benefit from Metal without doing anything.
 
I read a bit about Swift and played a bit with the new playground function in Xcode 6. It looks like Apple designed Swift just to replace Objective C, which is actually a good thing. I've seen some criticize that Swift is not "clean enough" or "should do some trivial thing in a better way" but that's really not the point. The point of Swift is to have something modern (compared to Objective C) to be able to completely replace Objective C without having to redo the entire runtime and API.

Therefore, its interoperability is very good. Swift codes can be linked with Objective C without problem. Data structures and classes written in Objective C can be used directly, therefore 3rd party libraries can still be used easily.

However, the main remaining problem is, will people start using Swift instead of Objective C? Personally I'll try it with smaller test projects, to see if there's any problem. Apple claims that its performance is good, but whether it could defeat a well written C code (codes inside an Objective C function is basically C codes) remains to be seen.

I also like the fact that it's not a scripting language. Just a personal taste thing :)
 
Wonder if it originated with an acquisition they made.

Or maybe they still had the Next team that created Objective C still around.

It may be high level and not offering same performance as C code but wouldn't Metal provide grater performance -- given the caveats about high performance mobile games with prevailing low prices.
 
Wonder if it originated with an acquisition they made.

Or maybe they still had the Next team that created Objective C still around.

It may be high level and not offering same performance as C code but wouldn't Metal provide grater performance -- given the caveats about high performance mobile games with prevailing low prices.

Neither, it's an internal project from the same guy that worked on LLVM (Chris Lattner). You can learn more about the process that lead to the creation of Swift in this article http://appleinsider.com/articles/14...tain-objective-c-which-it-now-aims-to-replace
 
The ObjC of today is significantly different than the one of 7 years ago when the first iOS SDK was released.

I expect Swift to have a similar evolution.
 
With Apple being such a successful, low-fragmentation market onto themselves within the spectrum of iOS and "A" series SOC devices, playing even more to that advantage and introducing their own new programming language and GPU brand-specific API makes sense.

Dev environment features like Playgrounds looks to make iOS an attractive target for a wider range of developers. Apple should also see increased dev lock-in to their platform, or, at the very least, facilitate multi-platform ports to run even better on their hardware.

Having GPU compute via Metal was a nice surprise. I've seen some work, while contrived to probe the potential of the GPU, which showed the gap between the G6430 and the dual-core Cyclone approaching 40x and more as the data set size and parallelism increased on some compute tasks (even still limited to a GL ES shader implementation).

Something only briefly highlighted at the WWDC stage presentation: WebGL on mobile Safari! And it appears to be quite performant, too. Even plenty of the older iOS devices could drive some fresh new web content at a healthy level of performance with WebGL.
 
With WebGL and FTL JIT available in WebViews, the performance gap between web apps and native code has narrowed. Web app distribution may become more feasible than ever as an alternative to the App Store, for some categories of applications.
 
With WebGL and FTL JIT available in WebViews, the performance gap between web apps and native code has narrowed. Web app distribution may become more feasible than ever as an alternative to the App Store, for some categories of applications.

There are still some functionalities which can only be done with a native app (push notifications, for example), but Apple is also actively pushing these functions into web pages.

Of course, security is probably still the weakest aspect (compare to a native app). For example, if you grant some permissions to a trusted web app, but the web page somehow got injected with some bad codes by an attacker, it could lead to serious security breach. Native apps, on the other hand, are much harder to compromise, assuming the users only download them from the official channels.
 
Is there a lot of 3d content served through web sites?

Wasn't there something like VRML or something like that which went nowhere?
 
Is there a lot of 3d content served through web sites?

Wasn't there something like VRML or something like that which went nowhere?
http://auzed.com/ try playing cube :rolleyes:

yes vrml is dead

I recently made an app that yes ppl create trees in their browser (not optimized ATM)
qualitree.jpg

though got sidetracked by working on a new webgl game, which is nearing release ( the major thing left is the AI to do, which is the most difficult :cry: hopefully I'll knock it out this weekend )
 
With WebGL and FTL JIT available in WebViews, the performance gap between web apps and native code has narrowed. Web app distribution may become more feasible than ever as an alternative to the App Store, for some categories of applications.

WebView has improved on both iOS and OS X too.

They also allow JavaScript to automate OSX applications (in place of AppleScript).

The native apps will still lead in performance and security (e.g., Metal, HealthKit, HomeKit, etc.). The new and "free" CloudKit effort is also interesting and it fits into Cocoa rather than web.
 
Somewhat OT, but probably not worthy of a new thread.

Anyone find it weird that we have no end of leaks/ photos/ specs/ screen sizes / tech drawings for the next gen iphone, and yet not a single shred of ANYTHING regarding the iwatch, not a battery or clasp or PCB or anything at all except uncorroborated speculation. We don't even have a firm 3rd party account of its general shape, whether its round, square, rectangle, or more of a band.

Yes the complexity of the iphone supply chain would tend to lead to many more opportunities for leaks, but you would expect some facet of the iwatch to have made its way into the public realm by now, given that iphone and iwatch are rumoured to launch around the same time.

Has Apple given up on its secrecy regarding the iphone, but is still being all "black ops" on the iwatch, or what's happening ?
 
From what I've read the iwatch will have a 2" rectangular screen/display.
With this, I also just read that. ;)

Seriously, with an iPhone, Apple has no choice but to have millions of them available at launch. An watch being a completely new product, they can afford to be conservative, launch with a small volume, and keep the whole logistics of that much more under control, and start production much closer to launch.

FWIW, I'm not convinced that there is a market as big for smart watches as there is for phones.
 
They did keep details about the iPhone mostly secret before the reveal. Again maybe because volumes were low?

Will be interesting to see if they really go with two bigger screen sizes instead of one as rumored.
 
Has Apple given up on its secrecy regarding the iphone, but is still being all "black ops" on the iwatch, or what's happening ?
My guess is that when Apple said they are doubling down on secrecy for future products they are focusing more on new products like the iWatch rather than updates like the iPhone.
 
https://developer.apple.com/library...ffs/index.html#//apple_ref/doc/uid/TP40008441

iOS 8 Beta 3 just added LDR ASTC support via 3 extensions:

GL_APPLE_texture_compression_astc_ldr
GL_APPLE_texture_compression_astc_lowprecision
GL_KHR_texture_compression_astc_ldr

So does this mean the vanilla PowerVR Series6 supports ASTC after-all rather than it being a new Series6XT feature or is custom ASTC support one of the reasons Apple calls it the A7 GPU rather than G6430? Or perhaps Imagination is just being conservative and not claiming ASTC support for the Series6 because it can't do both the LDR and HDR variants? And with ASTC support, I guess PVRTC2 is not coming to iOS.

They also appear to be expanding Metal use in the OS with CoreVideo now supporting Metal.
 
https://developer.apple.com/library...ffs/index.html#//apple_ref/doc/uid/TP40008441

iOS 8 Beta 3 just added LDR ASTC support via 3 extensions:

GL_APPLE_texture_compression_astc_ldr
GL_APPLE_texture_compression_astc_lowprecision
GL_KHR_texture_compression_astc_ldr

So does this mean the vanilla PowerVR Series6 supports ASTC after-all rather than it being a new Series6XT feature or is custom ASTC support one of the reasons Apple calls it the A7 GPU rather than G6430? Or perhaps Imagination is just being conservative and not claiming ASTC support for the Series6 because it can't do both the LDR and HDR variants? And with ASTC support, I guess PVRTC2 is not coming to iOS.
I'm pretty sure I wasn't hallucinating when I saw those ASTC extensions listed when the Beta 3 API diffs were first posted, but now they are gone. Hopefully it just means they were pushed back to later betas and the A7 GPU does support ASTC rather than Apple
accidentally posting the API diffs from the iPhone 6 build and that ASTC requires the A8 GPU. It would be good if ASTC could be the baseline compressed texture format for Metal.
 
Interesting. Some commentators have suggested that "Metal" ties Apple more closely to IMG than before in their mobile SOCs.

Does the theoretical inclusion of ASTC over PVRTC2 (if it doesn't show up in later builds) imply that ASTC is overall a better solution, or might it tend to suggest that Apple wants to get away from the proprietary TC going forward.

It takes around 3-4 years for IOS products to fall off the rear end of the product list. One could see that within that time frame, if Apple prioritises ASTC over PVRTC, a big portion of the app store games etc might no longer be dependant on the presence of PVRTC, leaving the option of dropping it altogether.

Reading far too much into it, and all pie in the sky, but might as well waste some board space !
 
Back
Top