Tag Archive for: ios

Hangout on Air: Following up on the Nexus 4 Switch

10 Jan

German journalist Gunnar Sohn asked me for an interview via Google Hangout On Air for his popular German blog Ich sag mal. Here it is as a follow up on my now widespread post about switching from the iPhone 5 to Nexus 4 (in German only).

Read more →

Finding a memory leak with Xcode 4 Instruments

25 May

Over at the fantastic Facebook iOS Developers group, we had a discussion yielding 40+ comments about a memory leak and how to detect it with Instruments.

I’ve created a brief screen cast based on the discussion we were having. While it actually shows pretty basic Instruments stuff, I still find even experienced devs struggling with the details.

Follow me on Twitter (@24z) for mostly iOS related tweets and if you’re not yet a member, join the tribe on Facebook.

Ignore ringtone mute switch during MPMoviePlayer video playback in iOS

24 May

Recently I stumbled across an issue in one of the apps we are creating over at GrandCentrix: When playing back video using the MPMoviePlayer framework, the ringtone mute switch switches off all audio.

This default behavior is significantly different from the one iOS users learned from the built-in YouTube app.

Worse: If users start video playback with the mute switch turned on, they might believe they’ve got a faulty signal, as they won’t here any audio right from the beginning.

Turns out, it’s easy to fix:

[obj-c title=”Ignore the ringtone mute switch”]

– (void)viewDidLoad {
[super viewDidLoad];
NSURL *url = [NSURL URLWithString:@"http://cdn.grandcentrix.net/video/ios/stream.m3u8"];
MPMoviePlayerViewController *moviePlayerViewController = [[MPMoviePlayerViewController alloc] initWithContentURL:url];

NSError *_error = nil;
[[AVAudioSession sharedInstance] setCategory: AVAudioSessionCategoryPlayback error: &_error];

[self.view addSubview:moviePlayerViewController.view];


Note that you have to add the AVFoundation framework to your project. In Xcode 4 to add a framework select the topmost node in the Project Navigator, select your Target, click Build Phases and hit the little + icon.

Adding Framework in Xcode 4

This and more tips frequently get discussed over at the great iOS Developers Group on Facebook. If you’re on Twitter, follow me (@24z) for mostly iOS related tweets!

TestFlight and In House / Enterprise IPA support

24 Mar

If you’re an iOS developer and haven’t been living under a rock, you might already love TestFlight.

In short, TestFlight dramatically simplifies the entire process of sending out test builds to your customers, partners and colleagues. Not only that, it also provides fantastic means of tracking installs and collecting feedback. If you really do not use TestFlight, yet, hop over now and register. It’s free.

One question, that I’ve seen asked many times is, whether TestFlight supports Enterprise builds. Quick answer: Not yet. It’s comming.

A little bit of background: Apple supports two kinds of iOS Developer Programs, Standard and Enterprise.

As a member of the Standard program, in order to distribute beta builds, you have to create Ad Hoc profiles and digitally sign your binaries with it. This ties the binary to a limited number of devices, identified by their unique IDs.

In addition to Ad Hoc code signing, the Enterprise program gives you In House profiles. Other than Ad Hoc, In House profiles are not tied to specific devices. Everybody who can get a hold of an In House signed binary, can install it. The device doesn’t need to be known upfront.

Currently, TestFlight is optimized for handling Ad Hoc builds, only. When you try to upload an In House signed build, you get this little message:

I’ve reached out to the folks at TestFlight and asked for a specific date. Haven’t heard back, yet. Once I get the info, I’ll update this post.

Apple’s latest Push Notification certificate changes demystified

10 Dec

This week, all iOS Developers received an email from Apple, stating:

“On December 22, 2010, the production Apple Push Notification service will begin to use a 2048-bit TLS/SSL certificate that provides a more secure connection between your provider server and the Apple Push Notification service.

To ensure you can continue to validate your server’s connection to the Apple Push Notification service, you will need to update your push notification server with a copy of the 2048-bit root certificate from Entrust’s website. This will not require a change to your iOS apps — this update only applies to provider servers.”

It’s pretty common for Apple to come up with relatively short term notices like these. Unfortunately, they also frequently lack any further technical documentation.

Based on discussions I’ve had with various other iOS devs during the last few days, I sense that there might be a little bit of confusion as to what exactly this announcement means.

Typical questions, I’ve seen:

  • Do we have to recreate our certificates or .pem files?
  • Do we have to install any additional certificate on our servers?
  • We never installed anything else than the production and sandbox .pem files as outline in Apple’s documentation. Do we now have to install a third certificate and change our existing backend code?

Over at GrandCentrix, Germany’s largest iOS development shop, we use our own Rails based Push Notification provider service hosted with Engine Yard and deployed through Amazon EC2 instances.

We never installed anything else than two .pem files. We created those with Mac OS X Snow Leopard’s Keychain Utility, exported key and certificate as .p12 files and finally converted them to .pem files using OpenSSL from the command line.

We never downloaded any additional certificates from Entrust’s website, nor did we install any special third party stuff into our local keychains.

I’ve contacted Apple and received some clarifying statements. I thought sharing them with other iOS devs might shed some light on the topic.

In a nutshell you most likely don’t have to do anything!

If you’re hosting your Push Notification service on a Linux box, any SSL connection is very likely already using Entrust’s certificate, even though you never manually installed it.

You can easily check this by using the Sandbox environment, which has already been switched to the higher security mode in March 2010. Bottom line: If your service successfully sends out APNs via Apple’s Sandbox servers today, you’ve got everything in place.

A little bit of background

Take a quick look into the /etc/ssl/certs folder. The point is: Most Linux distributions come with the required certificates preinstalled. That is, why you never had to manually install anything but got Push Notification services working anyway.

Here is an excerpt of the information that I’ve received from Apple:

“This announcement does not involve the certificate you receive from the Provisioning Portal. You do not need to generate a new Production or Sandbox certificate from the Provisioning Portal. Your existing PEM file should continue to work just fine.

This announcement is regarding other certificates (involved after your Provisioning Profile certificate is used to connect) to further validate the connection. Depending on the version of your Operating System and push technology stack, these certificates may already be installed and you didn’t even know they were being used.

The location of these certificates will be dependent on the operating system and push technology you are using. Mac OS X for example, keeps all of its certificates in the Keychain where many of the built-in scripting languages such as PHP, Ruby, Perl, etc. will automatically find the appropriate certificate. Other operating systems and or languages may have specific installation paths. If you determine that you need the new 2048 certificate, check the docs for the appropriate installation location specific to your implementation.

If the server & technology you are using to push to the APNS Sandbox environment is the same as that in your Production environment, then you most likley already have the appropriate certificate since it was probably included in the standard installation of the operating system or push technology stack.  Perhaps the simplest test you can perform is to test in the APNS Sandbox environment then make sure that the Entrust certificates in your Production environment match those in your Test environment.”


“When you connect to APNs to send notifications, that connection is a secure TLS/SSL connection. Part of the TLS/SSL protocol is the handshake where the system you’re connecting to sends its digital certificate to the TLS/SSL protocol software on your system (commonly OpenSSL or SecureTransport on Mac OS X systems). If you specify in your TLS/SSL options that you want to validate the connection to APNs, the TLS/SSL software on your system will check that the certificate was signed by a trusted certificate authority (CA). In the OpenSSL case, the verify_peer and cafile options are set in the stream_context.

With APNs, Entrust is the CA, so the APNs server certificate needs to be checked against the proper Entrust root certificate. There is a different root certificate for validating certificates with a 2048-bit public key vs. a 1024-bit public key, which is why the notice was sent out.

In the OpenSSL case, you’d add the new root certificate to the .pem file you specify in the cafile option. You can add that certificate at any time because all root certs in the cafile will be considered when the APNs certificate is validated.

The sandbox environment has been using a 2048-bit certificate since March, so you can test things in the sandbox to make sure you have the new root certificate installed properly.”

Hope this helps.

© Copyright 2017 by Ralf Rottmann.