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
Related
I'm looking for an open source for antitampering and Code obfuscation tool for my iOS project. Some library like Proguard in Android.
I found iXGuard and Dexprotector are paid tools. I'm looking for some open source tool.
Any help will be appreciated.
Xcode already does most of the obfuscation part
Find the points below:
Code tampering and obfuscation are hardly related terms because RELEASE native builds from Xcode destroy names of variables,
functions, etc So I would hardly bother with obfuscation - you just
do not need it.
Apple encrypts the code of the applications submitted to the App Store and restricts access to the machine code of the apps after
download to prevent easy static analysis of the application.
And what use case do you mean when you refer to anti-tampering? Do you mean the release of the same app with different resources (images + brand name) to the official app store? - I would hardly bother with such attempts.
And be prepared for any App Store rejection if you are doing any extra code obfuscation by using paid or any other third-party tools. Apple rejects most of the obfuscated things done through these tools. Apple rejection message looks like this:
3 Performance: Accurate Metadata Guideline 2.3.1 - Performance We discovered that your app contains obfuscated code, selector mangling, or features meant to subvert the App Review process by changing this app's concept after approval to the App Store.
https://developer.apple.com/forums/thread/113211
The code for a native app is stored in the form of a binary executable file, which is further encrypted; its decryption is performed only when the executable file is loaded by the processor into the random access memory and the whole decryption process happens at the hardware level. That is why it is very hard to create offline decryption tools. The only way to decrypt encrypted binary data is on a jailbroken device with a few special tools installed.
https://mentormate.com/blog/security-in-ios-protecting-ipa-file-content/
I have searched for a library that helps me to obfuscate the code and I've found this one:
https://github.com/rockbruno/swiftshield
When an app is undergoing the app store approval process, do the people at Apple check the warnings in your project, or do they only check for errors?
e.g. I have this warning on a lot of my NIB files:
Unsupported Configuration: Title set but using a system Identifier (These attributes are mutually exclusive; the Title will be ignored)
Will this be a reason for Apple to reject my app for the app store?
Apple won't check for warnings in your project, because they can't. They don't get the source code to your app, only the compiled binary and supporting files. So long as you follow the rules, you should be fine.
As for the specifics of your question: I very much doubt it, but nevertheless, you should definitely aim for a project which compiles without warnings, just as a general programming practice.
The keyword here is possible. I know of a few resources that talk about this and how to create static frameworks - here: https://github.com/kstenerud/iOS-Universal-Framework and here: http://db-in.com/blog/2011/07/universal-framework-iphone-ios-2-0/
I'm interested to see if it's possible to create a dynamically linked framework in an app that will not be submitted to the app store. I know it's impossible to write to the application bundle on a device without jailbreaking it. Is it possible to say, download a compiled framework file, put it in the documents directory and then access it via the application (think plug-in architecture). I know that if it is, you would be turned away from the app store for submitting it, but let's say this was an enterprise app, or an ad-hoc distributed app where Apple would not have to approve.
In my initial research I haven't found anything supporting that it is possible, but I feel like this may be such a fringe case that no one has published anything about it. Looking for a guru to give me a definite "no" before I give up.
not sure if this is what you are after but according to Apple there dynamically linked libraries even usable in iOS - for example the system libraries... XCode contains copies of them and references them via symbolic links...
see near the end of this http://developer.apple.com/library/ios/#documentation/Miscellaneous/Conceptual/iPhoneOSTechOverview/iPhoneOSFrameworks/iPhoneOSFrameworks.html#//apple_ref/doc/uid/TP40007898-CH6-SW3
just an idea:
put the .dylib + include files you want to use into the respective folders where XCode expects the system libraries... use themn and then put symlinks into your bundle on deployment... let the symlinks point where ou copy the .dylib
I believe the answer is no. Apps on the iPhone are sandboxed. That is, aside from Apple supplied frameworks, an app cannot access anything outside of its own build.
This is possible now with IOS 8 Xcode 6.
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.