I’ve just checked in the first working iPhone build!

Got it to run the juce demo - there’s a new project there to build it, and pretty much everything that you’d expect to work is working… All the graphics seem to be ok, audio’s running just fine, etc. Pretty good for a first draft!

Obviously when you put a desktop app on a handheld device it becomes blindingly obvious how badly all the controls work in that form-factor, and there’ll be some serious work needed to adapt Juce into something that’s versatile enough for all these targets, but this is step 1!

damn i got to buy an iphone, i always thought i’d never have to.

and a MAC ? the iphone sdk is only for osx i imagine.

…I know is step 1 … so I’m definitely jumping the gun … but I presume the build process can be cleaned up in terms of simulator/device/iphone/mac builds.

In terms of UI it doesn’t seem too bad. The sliders are no worse than UIKit sliders even though they are generally smaller! The viewport scrollbars are a bit tricky though. (I can’t scroll down in the Audio->File Playback tab very easily.)

Anyway, great work!

BTW The audio interruption stuff seems not to be working properly. It looks like you used a similar method to mine which seems not to work either now.

On the iPod touch (which is my main device platform):
[] starting with a headset NOT plugged in works fine (e.g., the audio->Synth Playback demo) [/]
[] plug in the headset: works fine[/]
[] unplug the headset
] the alert dialog pops up
[/][] clicking resume doesn’t work (i.e. audio doesn’t come back) [/][/list][/][/list]
I spent quite a while tweaking my code to get a robust method that worked - I haven’t tested it for a while so no idea when it broke (but it could have been os3.0->3.1.2 - I don’t have 3.0 installed on my Mac or iPod now).

I seem to remember testing my code on someone else’s iPhone (rather than pod) and never seeing the alert - so it might be tricky to reproduce.

Hey Jules,

Hats off for this!

If you can get this working stable, it will be a pretty important development I think.

Great work Jules. If you could make it stable Jules, the popularity of JUCE would sky-rocket. :smiley:

I have a partial fix which is to remove the dialog popup alltogether (which is weird since I played with this for a long time and it was the only way to get the iPod touch to resume playback when a HeadsetInOut was removed).

Seems to be discussed here:

This may help:

Anyway, perhaps Apple had bug reports and they partially fixed the issue which is why the dialog popup thing worked previously (and in hindsight maybe the reason clicking resume in the dialog rather than calling to reinitialise the audiounit in the interruption handler is that clicking resume runs on a different thread - again I thought I’d tried the performSelectorOnMainThread thing)

OK the partial fix (on 3.1.2 at least), is simply to remove lines 400-413 of juce_iphone_Audio.cpp i.e.,

        if (inInterruption == kAudioSessionBeginInterruption)
            isRunning = false;
            AudioOutputUnitStop (audioUnit);

            if (juce_iPhoneShowModalAlert ("Audio Interrupted",
                                           "This could have been interrupted by another application or by unplugging a headset",
                isRunning = true;
                propertyChanged (0, 0, 0);

This works fine when plugging/unplugging a HeadsetInOut (i.e., headphones with the little mic and the 4-contact minijack connector). This is regardless of whether you start with in plugged in or not.

It also works fine if you plug/unplug a Headset (i.e., headphones but no mic - a standard 3-contact minijack).

However if you unplug a HeadsetInOut then plug in a Headset there’s no audio out not even from the Speaker if you remove the Headset again. It works again if you plug the HeadsetInOut back in.

When this happens in my code (which is slightly different, but similar to the Juce Audio code) the audio route property is an empty string rather than Headset when it should be.

So mixing up Headsets and HeadsetInOuts seems to break this but otherwise works fine.


Can anyone test this behaviour on the iPhone? It handles interruptions differently

Thanks Martin! I’ve only got a 3GS to test with (and an old ipod touch with no microphone). It’s surprising (and annoying!) that they all behave so differently.

I’ll try your suggestion later and let you know how it runs on the phone…

This is wonderful news, thank you.

But I do seem to have some snags. One is that when I tried to build, I got a lot of missing symbols. I rebuilt the juce libs, and then retried, did a few other things, even added the amalgamted files, since that’s what the config.h seems to include - still no dice.

Then I got beaten around by Git. It doesn’t seem so easy to say ‘get everything from the head’ anymore. In this case, all the new stuff came in, but anything added wasn’t in my git repo, so I couldn’t revert it. Very odd.

If I try ‘git pull origin master’ again, it won’t do it since the remote files would overwrite the local, untracked files.

What’s the procedure?


OK, so it was a Git problem - it didn’t get the fresh juce lib project with the iphone target. In the end I had to checkout the head as a new branch over my existing branch. All very confusing in this context (compared to svn).

Still happy for any git & juce tips. Will I have to make a new branch every time I sync with the tip?


Martin - I tried your suggestion of removing the popup dialog, and it does seem to work really well on the 3GS. Plugging in headphones/headset etc all seems to work as you’d expect, so I’ve rolled this into the tip now.

Can I offer some simple iPhone suggestions, hopefully to get to something semi-usable early on?

Make a full-screen or full window tab component respond to swipes to change page.

Make a zooming viewport setup use multi-touch to zoom and pan/tilt.

Add a hidden native text field to accept OS text input.

With just those, we could make a fairly close app right there.

Did sockets pass across, by the way? Or do you have to rewrite for NSSocket or similar silliness?


Thanks, but that’s all pretty obvious stuff! It’s a fair amount of work to write it though!

Yes, sockets should be there - all the posix code went across unchanged and seems to work just fine.

Absolutely wicked stuff… Works like a charm. Didn’t expect that it would almost port the whole JuceDemo to the Iphone. Very well done.
A lot of people will have fun with this.

I didn’t want to make suggestions as you did a great job already but i can’t resist. How hard would it be to enable OpenGL for the IPhone?

Surprisingly easy - the iphone’s got very good opengl support. It’s not top of my priority list, but it’s not a difficult job to do.

As usual, Fab stuff, Jules!

You couldn’t add a few lines to the Juce Introduction ReadMe doc about how to create an iPhone “Hello World”-type application (i.e. what type of Xcode project/essential libraries and settings), please

Yup, I’ll write that as soon as I fully understand it all myself!

I only took me 1 1/2 hours yesterday to get Iphone app running that works as a remote for our Desktop Application. It sends out OSC messages to our VJ app using the Juce socket classes. Used the Jucer to design my MainComponent and copied a part of the LookAndFeel of our Desktop application so it even looks the same :wink:

Thanx Jules!

+1 An Iphone example project would be nice indeed.
I just copied the JuceDemo and stripped all the things i didn’t need.


wow - congrats on this!

Cant wait to try it out myself.