Archive for July 19, 2018

Thursday, July 19, 2018

NIOTransportServices: SwiftNIO and Network.framework

Cory Benfield (tweet):

The SwiftNIO team is thrilled to announce the release of NIOTransportServices. NIOTransportServices provides NIO users with a complete collection of EventLoops, EventLoopGroups, and Channels to help users use Network.framework with a SwiftNIO API.


Network.framework provides NIO with a number of powerful tools, including a richer connection lifecycle, access to a user-space TCP stack, and full support for operating on iOS and tvOS, including appropriate integration to the radios on mobile devices that is not possible with the socket API. Additionally it enables powerful networking technologies not currently supported in the mainline of SwiftNIO, such as MPTCP. Finally, it provides first-class integration with Apple’s platform TLS implementation, allowing users to avoid the burden of using OpenSSL or LibreSSL on Apple platforms.

Previously: SwiftNIO.

How Tinder Keeps Your Exact Location (a Bit) Private

Robert Heaton (via Tanner Bennett):

In 2013, it was discovered that the Tinder servers sent potential matches’ exact co-ordinates to the Tinder phone app. The app internally used these co-ordinates to calculate distances between users, and did not display them in the interface. However, an attacker could easily intercept their own Tinder network traffic, inspect the raw data, and reveal a target’s exact location. When the issue was discovered, Tinder denied the possibility that it was either avoidable or bad.


Tinder attempted to quietly fix this vulnerability by calculating distances on their servers instead of in their app. Now the network messages sent from server to app contained only these pre-calculated distances, with no actual locations. However, Tinder carelessly sent these distances as exact, unrounded numbers with a robust 15 decimal places of precision.


This new oversight allowed sneaky researchers to once again pinpoint a target’s exact location using a different, trilateration exploit. The researchers sent 3 spoofed location updates to Tinder to jump themselves around the city. At each new location they asked Tinder how far away their target was.

Tinder fixed this problem by rounding the distances. Straightforward rounding would also allow the location to be triangulated, but it turns out that they do something more clever.

Identifying a Real Apple ID Password Dialog

Dan Frakes:

My least favorite iOS dialog, asking for my Apple ID password (or is it App Store?) with no explanation why.

Dave Wood:

There’s a relatively unknown trick to this. When it’s really the system asking, you can’t multitask away from it. You must hit Cancel (or enter your password/OK). A fake dialog will let you swipe away. So always try to swipe up into multitasking before filling it out.

Previously: macOS 10.12.2 Impedes Safari Bookmarklets.

Update (2018-07-20): Sami Samhuri:

Just to keep everyone on their toes the Apple Store app shows an identical looking dialog that is part of the app itself.

Search at the Bottom

Theo Strauss:

In most apps, it’s common to see a search bar up at the top of the screen. On social media platforms, such as Facebook, Instagram, LinkedIn, and even Snapchat, the search bar is at the top of almost every main screen. In transportation apps, that style is almost ubiquitous.


Lyft took a different approach with their search bar. Instead of a floating field up top, they added it to an overlay towards the bottom-mid section of the screen. This simple change made it more accessible for almost 100% of users.

Previously: iPhone 5 Size, Why Smartphone Screens Are Getting Bigger, Switching to Smaller iPhones, iPhone Sizes, Switching to an iPhone SE.

Update (2018-07-20): Nick Heer:

I think there’s a deeper argument here for a more comprehensive adjustment to the way iOS, in particular, is designed. The layout of a typical app hasn’t really changed much since the first iPhone — from top to bottom: status bar, then navigation bar, then the main view, then a tab bar at the bottom. While that worked great on a 3.5-inch screen with an iPhone that easily fit in your hand, I don’t think that’s the case with today’s iPhones — and, if the rumour mill is correct, the smallest of this year’s models will be the size of the iPhone X.

Apple Doubling Down on Blocking Private API Use

Max Seelemann:

Rumor has it, that Apple is recently pushing to double down on eliminating any and every use of private API.

I’m convinced that this is ill-fated and hurts the platform as a whole. Users get worse experiences, developers worse products, Apple a worse platform.

Disclaimer: Of course, the use of private API is something to avoid at all costs. And it’s good that Apple is pushing for the discontinuation of its use.

But occasionally, it’s the last resort to solve certain problems. Problems that affect UX and totally should be addressed.


But as developer of apps, we need to ship things. Even if the issue was fixed now, apps should be as bug-free as possible on all the OS’es. iOS 11 is still the public release.

So… we need a solution. Let’s look at our options here.


1) Leave as-is, file radar, hope for eventual fix.

Results in bad experience for some users. They are not able to use the app because of a certain title. That’s a bug. Bad idea.

(There even is an app review guideline against bugs. More in a moment.)

2) Do not set a custom back title.

This leads to worse user experience – because we are no longer able to provide better context than what’s the default.

While this is a small example, take a dozen of them and you have a worse app. You get a worse experience for users.


5) Switch to non-native cross-platform toolkit.

I know this is radical. But you’re free to do whatever you want there. Style the UI with some CSS or something and no need for private API.

But IMO nobody will want to use your app. Bad idea. Native wins. UIKit is the one to use.


Know what? In my one and a half decades as professional app developer, all my apps broke in some way on every single new OS that came out.

Staring with Mac OS X 10.2, continuing to iOS 12 today.

But absolutely zero of these breaks were caused by the use of private API.

Marcel Weiher:

Pretty much the same in the last ~25 years or so. Incidentally, NeXTStep releases tended to not break things. System updates were downright boring.

I guess the issue for Apple is that not all developers are appropriately cautious about using private API responsibly. I would lean toward a policy of allowing private API use but not worrying about breaking the (non-existent) contract between releases. That provides an incentive to only use it as a last resort. As to the argument that private API lets apps do things and access data that they shouldn’t be able to do, those cases should be treated as OS bugs because App Review can’t guarantee that they will not be used, anyway.

Long-term, I expect that Swift will make it harder for developers to access private API, which will lead to more problems like Seelemann describes. Banning a workaround doesn’t make the original problem go away.

Along similar lines, Ash Furrow:

Apple’s stubborn refusal to provide a simple API to determine if you’re on an iPhone X causes developers to check for hardcoded screen dimensions, which is worse than developers making device-specific layouts.

Update (2018-07-27): See also: Open Radar.