I am investigating integrating Newsstand into a new iOS application, and want to know whether I can do this in a way that will still allow the app to run on devices that have not migrated to iOS 5.
Can anyone give me some feedback on how to architect an application to handle this?
I know it is possible to have a single application with different targets and sets of source files, but I would prefer to keep the codebase as unified as possible, and test for Newsstand features dynamically.
What you have to first of all it to weak-link your application to the NewsstandKit framework. This avoids that a device with an iOS version < 5 will crash due to the missing libraries.
Then at runtime you need to avoid calling NK methods and referring to NK classes which obviously are not available in iOS < 5. In such case you can use methods like NSClassFromString() or other obj-c runtime features that allow to detect dynamically the existence of these features.
A recommendation that I can do it in such case is to provide a pre-compiler directive that allows you to isolate all Newsstand stuff at compilation level. In this way you can try to compile using SDK 4 (if you have it) and see for compiler errors or warnings.
E.g. if you add in your Prefix.pch a definition like this
#define WILL_USE_NK
then you can bracket all NK references in this way:
#ifdef WILL_USE_NK
... your NK statements go here ...
#endif
Later, when you will compile the app with SDK4 you keep this definition so you will have a real SDK4 compilation valid for iOS4 devices (that you can test) and you will be sure that all your NK references are not used by an iOS4 app.
Then you must #undef this definition and compile with SDK5 (of course keeping some iOS 4.x as minimum target) before distributing the app.
Of course in this way you're not protected against all possible mistakes but at least you have isolated the NK references.
As far as the better strategy about the business logic of the application, this is up to you: it's not an easy task as now Newsstand takes care of many aspects, like background download and so on. Besides the magazine model is now split between your existing model and the NKIssue features, but all these are implementation details that go beyond this specific question.
Related
I know that Swift libraries can be statically linked, but I'd heard that linking in Swift would cause Apple's private API detectors to prevent it from going into the App Store? Is this true?
Found a link on an Apple Forum; hopefully it helps you, I haven't yet submitted anything to the AppStore yet.
But overall, seems like it's possibly more trouble than it's worth. If you get denied, you're possibly then going to spend time rebuilding/reworking.
Seems to be one point brought up, is to ensure you've added all files needed to compile your App, in your submission.
Link below:
https://forums.developer.apple.com/thread/94488
As of Xcode 9 beta 4, Xcode natively supports static libraries with Swift sources. but You have to use dynamic lib
Here is how Apple describes their dynamic framework:
Two important factors that determine the performance of apps are their launch times and their memory footprints. Reducing the size of an app’s executable file and minimizing its use of memory once it’s launched make the app launch faster and use less memory once it’s launched. Using dynamic libraries instead of static libraries reduces the executable file size of an app. They also allow apps to delay loading libraries with special functionality only when they’re needed instead of at launch time. This feature contributes further to reduced launch times and efficient memory use.
Source: https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/OverviewOfDynamicLibraries.html
Sometimes there are features added in new versions of iOS that are tempting to use, but you don't want to prevent users on older devices from using the app just because of one minor feature.
I've just added UIRefreshControl to an app, which was added in iOS 6. I don't really care enough to use a 3rd party solution (of which there are a number), I'd just like to not invoke the code that sets it up if I'm running on an older device. I suspect, being a static language, this isn't possible, but I thought I'd ask and see if there are ways of achieving this.
Obviously if I was just sharing the code I could do this with preprocessor macros, but I need to build the app to execute on iOS 5.1 + iOS 6.0.
This is perfectly possible, just check if a class is available:
if ([UIRefreshControl class]) {
// the UIRefreshControl is available.
}
It the same with new method on existing classes:
if ([self.someLabel respondsToSelector:#selector(setAttributedText:)]) {
// The label support attributed strings
}
Objective-c is not a static as you might think, just be sure that you weak link any frameworks that are not available in earlier versions of iOS.
I want to use the ffmpeg library (and maybe others) in my iPhone App.
But I have absolutly no idea how I can use the files that are in the downloaded zip, and get them to work in my XCode project.
I read something about .a files and frameworks. Maybe you can give me a description how to implement it?
1st, you're not allowed to do anything with open-source on apple market : basically, any open-source library tainting your code (thus GPL, but also LGPL as dynamic linking is forbidden) will have your application removed if spotted. The VLC case (removed from app store) proved that GPL is not compatible for app store license (look for app store and gpl and google and you'll find hundreds of links)
Second, you have to transform the code you received (say source code) into a static library (a .a file). To do that, you need to compile it, here you have basically 3 solutions:
put all the files into your xcode project and tweak until it works (thus not creating static library, directly merging the code with yours) : this seems the easiest, but will be a nightmare in terms of maintenance (each time you'll want to upgrade the statuc lib)
compile externally, by hacking the makefile to use the correct compiler (the one in for ios, in iphone platform folder)
add a subproject in your xcode project to compile the library
My advice goes for 2 (that's what I do with boost) but it's not a straight path
EDIT : don't forget that software video decoding will drain your battery and you might have poor performance
I noticed that there are different requirements for each platform here. I was wondering if it's possible to build a single project but with multiple targets where each target is Mac OS X (something like a CD / install build), Apple Mac Store, and iOS device.
IfIi'm going about this the wrong way then I'd love to know! I mostly develop on the PC but with the state of the App Store I'd love to spread out as much as I can!
Keeping separate targets for the Mac app store and an independently-distributed Mac application is simple. You just need to ensure that your receipt validation code is conditionally included on the app store target and not in the other target; and your custom licensing scheme is included the other way round. Things get a bit more complicated if you target different operating systems in the two targets, but they're not insurmountable: you can test for the existence of classes or selectors at runtime to ensure you never call newer API on older systems.
By the way, it's also worth having separate Info.plist files for these targets. Partly because you don't need or want to include things like Sparkle properties in your app store target, but also because each target should have a unique bundle identifier. The app store does odd things when you have an app installed that it thinks came from the store but really didn't, and you don't want to risk your updater or Apple's trying to update the app deployed via the other mechanism. But that's not really about organising your Xcode project, it's a deployment issue.
For the most part, yes. All Mac/iOS apps can be written in Objective-C and the code is very similar. However, you must bear in mind that iOS devices have different screen sizes from the Mac and even from each other. That means that the input metaphor is different, and that the UI is different. While it is possible to do what you want, it's not advisable to just code once and compile thrice.
That said, I don't use Xcode 4 so I can't tell you about that. Of you are looking to do different builds for different devices, you will want to write your app logic and your input logic as separately as possible. Then, you create multiple targets, one for each build. You define compiler flags for each target. In your code you will use those flags to use the appropriate code for your build.
At least as of 3.2.5, this is absolutely not a problem. You won't necessarily be able to apply all of your build settings project-wide, but you can specify them on a per-target basis.
Just add the appropriate-type target (Cocoa Touch, Cocoa, etc.).
I'm whipping up a short specifications/requirements document for a small prototype iPhone app project. Describing the basic functionality and behavior is not an issue for me. But, since my mobile application and iPhone development knowledge is very weak, I'm not really sure what else should be in such a document regarding best practices and such.
Example: In my programming world (server side Java), when spec'ing a project for outsourcing, I state that the project must pass static bug analysis by FindBugs.
Example: I understand that there are API calls Apple does not want app developers invoking. These can be cause for having an app rejected from the app store. But I'm not sure how to say that we want Apple's guidelines respected. (I don't even know how to test for that.)
What should I include in a two-page requirements and specification document that is specific to iPhone app development?
These are some points you can mention
1. The application should be developed based on Apple's user interface guidelines
2. There should not be any private API call inside the project which makes the application rejected from apple
3. There should not be any memory leak or excess memory allocation issue during the application running state
4. The application should be supported in all iOS after [your option]. (It mainly depends on the features used in the application)
5. The application should be supported in iOS 4
6. The application should work properly on iPhone 4
Hope this helps
A private API wont be mentioned in any header file or in the documentation so one way to test for that would be to manually go through the source files and search for the functions used in the headers and documentation to see that they are there. It's really not feasable if the project grows but for a small app it could work :)
In addition to the things already mentioned here, I'd add a few more:
The app should work fast, no action should give the user the feeling, the device is doing something
Everything that takes a while should be run in background and even better, be cancelable
Make sure you use animation only where it makes sense but not too seldom. A smooth feeling is most important for users.
These things also imply that you try to minimize application startup time.
There are often tricks to work around performance issues. The feeling a users gets from your application is not how fast it is, but how fast if feels. In my opinion this is the single most critical requirement, besides obvious ones like no crashes etc..
What's the problem with using a private API?
Moreover, I would add that it will be tested on iPhone 3G, 3GS, iPod, 4, all with iOS4 and 3.