I haven't done any iOS development before but is there any real reason why a tiny app with what seems to be ~100 lines of code needs to be split into several small files with even fewer lines in them?
As far as I can see, the actual work is performed by around 5 lines of code in this file, which reads a configuration value, performs two string comparisons, and outputs to 2 text fields:
AppDelegate.m and main.m are boilerplate. They are generated by Xcode when you create a new project. Often you don't change them. The ViewController is where you should start examining the code.
That's not much verbosity/fluff. It's the typical default auto-generated code files; basically the author said "new project" and filled in a few lines. No need to hand-optimize this into minimum files.
ETA: With some cut-and-paste & removing stubs, and preserving the storyboards, the whole thing can be reduced to 20 lines in just main.m, smaller if you shift into "obfuscated objective-c" mode.
Objective-C isn't too bad. I've certainly had more boilerplate to deal with on various other platforms. In terms of names, it is verbose though. It's one of the things I really like about it.
However, the problem is that MGCopyAnswer is a private method, and thus you have to define an interface for it. You can't do that in Swift, however you can do it by creating a bridging header for Swift.
So you'd need to add a bridging-header.h to the project, then set the compile target up to use the bridging header, and finally add this to the bridging header:
Most people won't care but let's say the Samsung gets another half hour of battery life. For some people that may be worth the hassle of exchanging (and restocking fee?).
Now everyone can run and test their own app on a device—for free. You can run and debug your own creations on a Mac, iPhone, iPad, iPod touch, or Apple Watch without any fees, and no programs to join. All you need to do is enter your free Apple ID into Xcode. You can even use the same Apple ID you already use for the App Store or iTunes. Once you’ve perfected your app the Apple Developer Program can help you get it on the App Store.
See Launching Your App on Devices for detailed information about installing and running on devices.
My theory was that the whole developer key thing was a very effective piracy countermeasure — registering and paying $100/year (iirc) is expensive and inconvenient enough that it's easier to just buy things. What has changed?
I believe that you still have to build it to install it on your iPhone, so the likelihood of this being used for piracy is low. Not many commercial apps will have their source code available publicly.
Motivation was basically to have an open source version of the tool, which didn't relay information back to a server or use advertising. Plus having people install unauthorised apps using a leaked/dodgy enterprise distribution certificate is a dangerous game; having an open source tool allows people in the know to install it on their own devices, safe in the knowledge what it's going to do.
I was curious what the readme was referring to, this[0] apparently is the macrumors post and tool[1] this is a response to.
[0] http://www.macrumors.com/2015/09/29/a9-chip-split-tsmc-samsu...
[1] http://demo.hiraku.tw/CPUIdentifier/
I haven't done any iOS development before but is there any real reason why a tiny app with what seems to be ~100 lines of code needs to be split into several small files with even fewer lines in them?
https://github.com/WDUK/A9ChipSource/tree/master/A9ChipSourc...
As far as I can see, the actual work is performed by around 5 lines of code in this file, which reads a configuration value, performs two string comparisons, and outputs to 2 text fields:
https://github.com/WDUK/A9ChipSource/blob/master/A9ChipSourc...
In other words, is this level of verbosity/"fluff" typical of iOS apps?
AppDelegate.m and main.m are boilerplate. They are generated by Xcode when you create a new project. Often you don't change them. The ViewController is where you should start examining the code.
Of course, you have the .h files too. With Swift these go away so there's fewer files. Finally, you can do scripting that doesn't have any boilerplate: http://www.h4labs.com/dev/ios/swift.html?age=10000&q=scripti...
Most of what you see is the boilerplate of generating a new iOS app.
You're right, all of the interesting code is in ViewController.m, and if this were extracted to a library it would be much smaller.
I think the point of this repo is a demo app that you can build and run on your phone to find out which chip manufacturer you have.
That's not much verbosity/fluff. It's the typical default auto-generated code files; basically the author said "new project" and filled in a few lines. No need to hand-optimize this into minimum files.
ETA: With some cut-and-paste & removing stubs, and preserving the storyboards, the whole thing can be reduced to 20 lines in just main.m, smaller if you shift into "obfuscated objective-c" mode.
Exactly, I spent less than half an hour writing this up, and wasn't aiming for the lowest LOC possible. This is all mostly boilerplate.
A quick port to Swift: https://github.com/mnem/SwiftA9ChipSource. The functional bit is in https://github.com/WDUK/A9ChipSource/blob/master/A9ChipSourc....
Objective-C isn't too bad. I've certainly had more boilerplate to deal with on various other platforms. In terms of names, it is verbose though. It's one of the things I really like about it.
I should have come to the comments before trying to work out which file the functional code was in.
How do you do this in Swift?
CFStringRef val = (CFStringRef)MGCopyAnswer(CFSTR("HardwarePlatform"));
NSString* chipIdentifier =(__bridge NSString * _Nullable)(val);
Theoretically just:
let u = MGCopyAnswer("HardwarePlatform")
However, the problem is that MGCopyAnswer is a private method, and thus you have to define an interface for it. You can't do that in Swift, however you can do it by creating a bridging header for Swift.
So you'd need to add a bridging-header.h to the project, then set the compile target up to use the bridging header, and finally add this to the bridging header:
#include <CoreFoundation/CoreFoundation.h> #if __cplusplus extern "C" { #endif CFPropertyListRef MGCopyAnswer(CFStringRef property); #if __cplusplus } #endif
That's not correct. You can define it with @asmname.
Thanks, I didn't know about that. I've since written a blog post to explain how to do it in Swift (also because I wanted to try it out) here (http://appventure.me/2015/09/30/getting-iphone6s-foundry-fro...) I've included your helpful info. Thanks!
I hope this code finds way into mainstream system information apps on App Store.
Why would I care where the processor in my phone is made?
Most people won't care but let's say the Samsung gets another half hour of battery life. For some people that may be worth the hassle of exchanging (and restocking fee?).
Please pardon my ignorance...
My impression was that only apple approved, app-store delivered software could run on iPhone/iPad/iWhatever ...
Am I wrong to be surprised to see an "iOS utility" hosted on github ? What am I missing here ?
Anyone can build it and put it on their device, all you need is Xcode and a Mac in addition to your iOS device.
iOS apps can be built/signed/installed from a Mac running Xcode 7 without any extra requirements. I'm surprised this fact hasn't gotten more press.
Now this is interesting, had to dig it out:
Free On-Device Development
Now everyone can run and test their own app on a device—for free. You can run and debug your own creations on a Mac, iPhone, iPad, iPod touch, or Apple Watch without any fees, and no programs to join. All you need to do is enter your free Apple ID into Xcode. You can even use the same Apple ID you already use for the App Store or iTunes. Once you’ve perfected your app the Apple Developer Program can help you get it on the App Store.
See Launching Your App on Devices for detailed information about installing and running on devices.
( From the feature list for xcode 7 — https://developer.apple.com/library/prerelease/ios/documenta... )
My theory was that the whole developer key thing was a very effective piracy countermeasure — registering and paying $100/year (iirc) is expensive and inconvenient enough that it's easier to just buy things. What has changed?
I believe that you still have to build it to install it on your iPhone, so the likelihood of this being used for piracy is low. Not many commercial apps will have their source code available publicly.
How did he know what manufacturers those ids mapped to?
https://github.com/WDUK/A9ChipSource/blob/master/A9ChipSourc...
https://github.com/WDUK/A9ChipSource/commit/118eb9538d902422...
Hi guys, I'm the creator of this little utility. Just noticed a flood of Stars on the repo, and thought it might be posted here.
Information on the chip identifiers was derived from the original closed source tool, and theiphonewiki (https://www.theiphonewiki.com/wiki/S8003 and https://www.theiphonewiki.com/wiki/S8000).
Motivation was basically to have an open source version of the tool, which didn't relay information back to a server or use advertising. Plus having people install unauthorised apps using a leaked/dodgy enterprise distribution certificate is a dangerous game; having an open source tool allows people in the know to install it on their own devices, safe in the knowledge what it's going to do.