Archive for June 6, 2014

Friday, June 6, 2014 [Tweets] [Favorites]

Recording iOS Screen Over Lightning to Mac

Benjamin Mayo:

Apple has added a handy feature into OS X to easily capture the screen of an iPad or iPhone on the Mac itself. Apple positions the feature as a way to help developers quickly make app previews, which Apple introduced as part of iOS 8’s improvements to the App Store, but there is no reason why this couldn’t be used by others for different purposes.

[…]

In testing, the recording is currently extremely laggy. It is reasonable to expect video quality will improve significantly as iOS 8 and OS X Yosemite approach public release.

This URL Shortener Situation Is Officially Out of Control

Scott Hanselman:

When I visited it for the FIRST time, I got this lovely HTTP interaction. That’s SEVEN HTTP 301s, count them, 7, before I get to the destination page.

It would have been 8 redirects if I’d counted t.co as well. Note also that after it bounced around three of Slate’s URL shorteners, it also goes through goog.gl as well.

[…]

Every redirect is a one more point of failure, one more domain that can rot, one more server that can go down, one more layer between me and the content.

Beta App Review

Ole Begemann:

Following the TestFlight acquisition a few months ago, Apple announced at WWDC yesterday that they will allow beta app distribution through the App Store in the future.

Overall, the program looks great, with developers being allowed to invite up to 1,000 beta testers per app and testing privileges being bound to usersʼ Apple IDs instead of specific iOS devices.

[…]

So it seems that your beta app has to go through review at least once, but thereafter Apple may allow you to skip the review unless you make significant changes (whatever that means).

Metal

Ryan Smith:

Upon hearing Apple’s Metal announcement, perhaps the greatest surprise was that iOS developers were in a position where they needed and could benefit from a low-level API like Metal. In the PC space we’ve been seeing low-level APIs rolled out as a solution to the widening gap between CPU and GPU performance, however the SoC class processors in Apple’s iOS devices are a very different beast. As one would expect for a mobile product, neither the CPU nor the GPU is high performance by PC standards, so why should a low-level API be necessary.

The answer to that is that while SoCs are lower performance devices, the same phenomena that has driven low-level APIs on the PC has driven them on mobile devices, just on a smaller scale. GPU performance is outgrowing CPU performance on the SoC level just as it has been the PC level, and even worse, SoC class CPUs are so slow that even small amounts of driver overhead can have a big impact. While we take 4000 draw calls for granted on desktop hardware – overhead and all – it’s something of a sobering reminder that this isn’t possible on even a relatively powerful SoC like the A7 with OpenGL ES, and that it took Metal for Crytek to get that many draw calls in motion, never mind other CPU savings such as precompiled shaders.

Update (2014-06-13): RenderingPipeline:

We can see, that a lot of complexity is hidden from the programmer and that a lot of tricks (probably way more than I have mentioned here) have to be performed to hide what is actually going on. Some of those tricks make the life of the developer simpler, others force him/her to find ways to trick the driver (e.g. the mentioned “useless” draw calls to force the driver to cache states early on) or to learn the possible side effects of API calls (for example which can stall the GPU and how to force a stall to reduce latency).

Some graphics APIs now try to remove most of these tricks by exposing more of the actual complexity – in some cases by leaving it to the program so solve the resulting problems. It’s been said that the graphics API of the PS3 went in this direction (as I’m not a PS3 developer I don’t get access to the documents to check and even if I would be one, the NDA prohibits all devs from describing any details), Mantle is going in this direction (we will see more about how it’s done by AMD when the documents get released), as will Microsoft with DirectX 12 and now Apple is doing the same with Metal.

[…]

Each draw costs some time on the CPU and some time on the GPU. The Metal API reduces the time spend on the CPU by making state handling simpler and thus reducing error checks by the driver if the state combination is valid. Precomputing states also helps: not only can the error check be done at state build time, the state change itself requires fewer API calls. Being able to build command buffers in parallel also increases the number of possible draw calls if the application is CPU bound.

The rendering on the GPU on the other hand is not faster, an application that only makes a few calls to draw very huge meshes will not benefit.

Update (2014-06-14): Guy English:

The issue with OpenGL is that an incredibly complicated state machine is being addressed in an atomic fashion on a per function basis. By that I mean that each call into OpenGL required a check to make sure the state was valid for the device. OpenGL error reporting is such that no functions return an error code. Instead they set a GL local variable that’s accessed though the glError() function. The lack of immediate error returns, as well as other features of the API, derive from its earlier days where it was envisioned as a largely asynchronous affair. Commands would be buffered and fired off to the renderer and there would be only occasional synchronization points.

While that’s a laudable abstraction, that’s not what we’ve ended up with in the real world. Our ability to render 3D graphics is coming closer to the CPU rather than further. Intel has been shipping respectable (yes, gamers, I know) parts for a couple of years that perform well. Meanwhile, Apple’s A7 has a tremendous amount of capabilities that haven’t, and can’t, be unlocked via the OpenGL API. Integrated memory and graphics processing are not what OpenGL was designed for.

[…]

Metal turns that that upside down. Rather than making discrete state changes (flipping switches) directly in the driver Metal allows you to order up a set of state that’d you want applied. If it can’t be done you’ll know. If it can then that set of state is good and can be applied, without further checking, to other rendering operations and contexts. Metal turns a set of many tiny decisions into an opportunity to green light a plan.

WKWebView

Mike Beasley:

As of iOS 8, however, it seems that decision has been reversed. All apps will now be able to use the same improved JavaScript engine that powers Safari. That means Google’s Chrome browser on iOS will now be just as quick as Safari, as will the pop-up browsers embedded in apps like Twitter and Facebook.

TJ VanToll:

Hybrid apps are never going to compete with native on performance, but as hybrid performance improves, the hybrid development approach becomes good enough for an increasing number of apps. With the performance improvements that iOS 8 offers, and performance increases on other platforms — such as Android 4.4 switching to a Chromium-based web view — things are looking up for hybrid development.

I’m glad to have been wrong about FTL JIT. I still think it’s offensive that Apple prohibits development of alternative Web rendering or JavaScript engines (rule 2.17).

iOS 8 and Yosemite Extensions

Federico Viticci:

The possibility to enrich the functionality of apps and customize the operating system will come with new guidelines and rules developers will have to follow. For one, extensions will always come embedded inside apps users download from the App Store: an extension will be bundled with an app, and developers won’t be able to release standalone extensions on the App Store or submit apps that only contain extensions.

[…]

The even bigger reveal from Federighi’s presentation were Actions, app extensions that will allow users to view or manipulate content inside another app. Federighi used two examples to show the “view” and “non-view” nature of extensions: a Bing translate action, which used a feature from the Bing app to translate Japanese text in Safari without showing any additional interface; and a Pinterest web clipper, which presented a custom-designed clipping tool to save an image from a Safari webpage into the Pinterest app without actually launching the app.

[…]

More importantly, Actions will nurture the creation of rich workflows that aren’t possible with URL schemes. In a demo shared with developers at WWDC, Apple showed an image annotation tool capable of editing an image from a Safari webpage and insert it back into the webpage when done. It was reminiscent of Markup, a feature of OS X Yosemite that also happens to work as an Action extension. This kind of visual, interactive inter-app communication will result in user-friendly and powerful workflows that will be akin to "mini apps" available right inside a host app without having to switch contexts or be limited by bookmarklets.

[…]

Finder Sync will allow apps that sync a local folder with the web to modify the Finder interface with badge icons and custom menus. The latter seems primarily aimed at services like Dropbox, which had to reverse-engineer the Finder to put sync icons and logos on top of folders.

[…]

Zorn, who modified the default iOS keyboard with extra rows and buttons in his apps, says he is “thrilled” that Apple is enabling custom keyboards on iOS, but also “a bit disappointed by some of the restrictions”. For example, Apple’s won’t allow keyboards to have any kind of selection controls, so tweaks such as the popular Hooper Selection concept won’t be allowed on the App Store.

Mac OS X Yosemite Under the Magnifying Glass

Min Ming Lo:

Apple revealed a sneak peek into Mac OS X Yosemite earlier this week. Not surprisingly, Apple updated its desktop OS to match iOS 7’s design language. The new OS X now embodies a brighter and flatter styling, coupled with icon updates, font changes, and translucent materials. Here’s a quick look at the visual design changes in Yosemite and my impressions of them.

I generally like the new application icons (except for System Preferences) and Dock. I’m not fond of the bright blue folders, the thin and hollow toolbar buttons, the translucent and sidebars and title bars, or the readability of Helvetica Neue.

Update (2014-06-18): There’s a new (and better) System Preferences icon in DP 2.

Update (2014-08-01): Paul Kafasis:

The simplification generally works well. These new icons are still recognizable as representations of real-world objects, without unnecessary embellishments or detail. However, Safari’s new icon is somewhat problematic.