Get iOS Device


Hey, here’s a little helper function to figure out what kind of iOS device is being used:

    #include <sys/sysctl.h>

            String getPlatform()
                size_t size;
                sysctlbyname("hw.machine", nullptr, &size, nullptr, 0);
                HeapBlock<char> heap(size);
                sysctlbyname("hw.machine", heap.getData(), &size, nullptr, 0);
                String platform(heap.getData());
                DBG( "found platform: " << platform);
                return platform;

in the Simulator, it’ll return “x86_64”, but on actual iOS devices, it’ll return the full device identifier, i.e. iPhone8,1 or iPhone10,6
here’s an unofficial list of device identifiers:


Hi, I use:

String device = SystemStats::getDeviceDescription();

Not sure what this will return on simulator as not tried, but returns either iPad or iPhone on devices. Not sure if any further detail is available with different calls.



yeah, that just says “iPhone”. it doesn’t say which model of iPhone or iPad.


perhaps the JUCE team wants to update

String SystemStats::getDeviceDescription()
   #if JUCE_IOS
    return nsStringToJuce ([[UIDevice currentDevice] model]);
    return String();

so it provides the actual device identifier? @fabian @ed95



Hi Ed - I haven’t pulled latest yet, but if the return value has changed is this a breaking change?



Instead of returning iPhone or iPad it’ll now return something like iPhone7, 2 for e.g. an iPhone 6 so it shouldn’t break anything and just adds some extra info.


But if we’re comparing the result to see if it returns iPad or iPhone this will now fail?


I can add something to the breaking changes doc for this, but it’s just a matter of changing your comparison from SystemStats::getDeviceDescription() == "iPhone"; to SystemStats::getDeviceDescription().contains ("iPhone");


Yes, I agree - but as the change will be a silent one when people pull from dev (or main branch once it moves over) then they’re not going to know unless it’s listed as a breaking change. I only know because I happen to have posted on this mail, otherwise when I next pull from dev I’d have had to hunt for the break…


After you pull the latest tip from develop, why wouldn’t you read the commit messages to see what’s been updated? That’s the easiest way to know if a change is breaking without requiring a special alert from the JUCE team, no?


well, sometimes i go weeks without pulling so there’s a lot to go through - and there’s also the person who pulls from master once every 6 months - are they really going to read every commit comment?

I thought the purpose of the breaking changes announcements was to alert people to things in their code that silently (i.e. no compiler errors) will behave differently. It really was only a suggestion…


sure sure, i wasn’t implying anything. I know that there are a lot of users on here who pull from develop nightly.


yeah, understood - once I’m getting close to a release i tend to stick with a version for a while, just in case something goes awry