I've produced a project that runs fine on iOS 8 (there are no unit tests though). It's a rather large project, and I don't have time to test all the features on a different operating system. I however, want to determine whether it would run with the same stability on iOS 7.
Of course, there are plenty of reasons that it wouldn't aside from the fact of using iOS 8 specific methods, however I've had a google for a script or process that would have:
functionality to determine whether my Xcode project has iOS 8 specific methods, and if so, where.
For instance, this method has tripped me up before:
- (BOOL)containsString:(NSString *)aString NS_AVAILABLE(10_10, 8_0);
Is there anyway of pulling all the method declaration information, and the OS availability of it, and then using that to parse the current Xcode project to determine whether I'm using code that will only run on iOS 8?
Or is this an impossible ask?
Related
Sorry if I use the wrong terminology, I'm not an iOS developer so I'm mapping everything back to equivalent features in Windows ...
If I write an iOS application that creates controls using standard UIKit functions, and I run that exact same application on various versions of iOS, will the application look slightly different on the different versions of iOS? Or does the application always use the styling of the version of iOS I select for the target version in Xcode?
And in a related question, is there a web site somewhere showing how the various controls have changed their look through the various iOS versions?
Generally no. Since iOS7 to current iOS release - all standard UIKit controls look the same. On iOS6 and lower things are drastically different. If you target iOS7 and up (As most devs do now since hardly anyone is on iOS versions lower) - you can be rest assured that all usage of standard UIKit controls will look exactly the same.
I have a small app written in Objective-C. It was something like 3 Mb of size.
When I added one Swift file the size of my archive grew up to 10 Mb.
What i found is that Swift embeds it's actual library in every project it is used in. This is necessary to be able to run the project even in case that Swift library changes in the future.
But 8 Megabytes is a huge overhead for small projects. Maybe there is some information about when Swift will get stable library that will be embedded in OS?
Or maybe there are some flags that can be added to the project that force compiler to use standard Swift library embedded in iOS?
Swift is still changing. So at the moment the runtime has to be included with every app. Maybe Apple will include the Swift runtime in iOS once the development of Swift slows down.
Swift source code had to be adjusted after almost every release of Xcode since the 6.0 betas. The runtime has changed at the same time the compiler has. iOS can't use a standard swift library, but has to use the one the app was compiled and linked with.
See this explanation by Apple.
you can trust that your app will work well into the future. In fact, you can target back to OS X Mavericks or iOS 7 with that same app. This is possible because Xcode embeds a small Swift runtime library within your app’s bundle. Because the library is embedded, your app uses a consistent version of Swift that runs on past, present, and future OS releases
While your app’s runtime compatibility is ensured, the Swift language itself will continue to evolve, and the binary interface will also change.
As Swift changes, those frameworks will be incompatible with the rest of your app. When the binary interface stabilizes in a year or two, the Swift runtime will become part of the host OS and this limitation will no longer exist
Not using Swift is the only way to keep your app size down.
Since Swift 3.0 won't deliver a stable ABI, this will remain the same for the time being. So in a year or two probably translates to Swift 5.0 in 2018.
Some background info: Syntax color/highlighting and auto-suggest stopped working correctly. I read a lot of questions about how to fix this but none of them helped me as they were related to Derived Data.
I'm learning Swift from some online tutorials, and noticed my syntax highlighting was different to that of the course teacher's. Then I noticed that when I create an instance of my struct, and use the dot syntax after the instance, Xcode didn't auto-suggest the struct's functions and variables, whereas it does in the downloaded version of the project. After some investigation I noticed that a key difference between my project and the teacher's is that my project has a Deployment Target of 8.1, whereas the teacher's has 8.0. I changed mine to 8.0 and immediately the syntax highlighting was restored and I could access the struct instance's functions and variables.
I'm guessing this may be a bug in Xcode, but perhaps I have something misconfigured in Xcode? I'd be grateful if anyone could explain how/why this bug occurred and what is best practice when choosing the Deployment Target.
The setting is located at Project > General > Deployment Info
I hope the above info may help others who encounter this issue.
Deployment Target is the iOS version that your app is intended for. This does not mean it is incompatible with other versions, simply that it is designed to work best on that version. Generally, using the app on a device with a newer version of the OS is much safer and less likely than using the app on a device with an older version of the OS. There's actually a lot of restrictions around installing an app with a deployment target higher than the OS version on the phone.
The most common deployment target right now is going to be 7.x, as most apps were updated when iOS 7 first came out (there was a pretty big change in UI standards and SDK functionality from 6 to 7), and iOS 8 isn't too terribly different from 7, so there's no need to restrict it and/or write new versions of the app for the new SDK. By having a deployment target of 7.x, you should ensure that the app works well on 7.x and all higher versions, including 8.x. You should also have the lowest deployment target you can that's reasonable - so, a purely iOS 8 app should ideally be targeting iOS 8.0. You'll save yourself a lot of PR and invalid bug reports from users who don't understand versioning.
In your scenario, it sounds like there may be a bug in Xcode when using the iOS 8.1 deployment target. You might want to check and see if your docs are downloaded. Go to Xcode -> Preferences -> Downloads and ensure everything is downloaded. I'm not sure if these are actually used in syntax highlighting and completion code, but it's possible. I would also do clean the build folder (Product -> Hold Alt -> Clean Build Folder). Again, I'm not sure, but I think there's just some small thing that's not clicking here. I'm assuming you cleared Derived Data based on your first paragraph - if not, do that (Window -> Organizer -> Select Project -> Delete).
CorePlot looks like the best library going for the iPad apps I'm looking into, but I've been fighting all day just to get it to compile in an OS 6.1 project set to use Core Date, ARC, and unit tests.
I want to use those specs, but I'm starting fresh, with no other code that needs salvaged, so it occurred to me that rather than fight through the tutorials that don't address installation in ARC; and through the fixes for ARC that never seem to get me all the way to compile-able; that I could easily take any bare-bones project with those basic specs and start bringing in the simpler additions I've already figured out.
Anything like that out there?
All of the CPTTestApp example apps for both Mac and iOS have been converted to use ARC. This was done after the 1.1 release, so at the moment you'll need to pull the latest code with Mercurial to see the changes.
Since the 1.0 release, no changes to the Core Plot project is required to use it in an app that uses ARC. The Core Plot header files will compile under all supported SDKs with and without ARC. Include the Core Plot static library in your app, either the pre-compiled version or one built as a dependent project, and it will link and run just fine.
Core Plot does not use ARC internally because it still supports older systems that cannot use it. It will be updated when the minimum supported system is increased to one that supports ARC on both Mac and iOS.
I have an old app I maintaining. The app was first compiled on XCode 4.2. If I take the exact same project that works find and compile it on XCode 4.6 I'll get weird bugs such as ViewControllers not refreshing, Back doesn't work as it should etc'. If I'll take the same project and recompile it on xcode 4.2 on my other machine everything will work fine. Before I'm digging into the code, can someone give me an idea why something like this may happen? My main suspect is the Base SDK of each Xcode. Does that make sense?
I couldn't tell you if there will be a difference between 4.2 and 4.6, but historically the iOS frameworks on the device (and, to a lesser degree, the simulator) do adapt slightly depending on what version of the SDK an application was compiled against. You can't rule it out.
A classic (though now ancient) example is backgrounding. Apps built against older SDKs were quit when the Home button was pushed, rather than getting the newer behaviour. More recent (but subtle) examples have included several changes to table views and changes to device rotation.
You should not attempt to build with an older SDK using a newer compiler. Apple doesn't support that kind of configuration. You should always use the latest SDK. And you wouldn't want to pretend these problems don't exist, anyway: The bugs are real, they were just hidden before.
It's unlikely that you won't be able to fix those bugs in such a way that the older versions of iOS continue to function (though you may discover it opens a can of worms that you decide isn't worth fixing for older OSes).