I have a general question regarding bundles, libraries and custom frameworks on the iOS. I've seen many topics about this on SO and searched far and wide on the net, but I still can't come to an answer without finding another site or post contradicting or confusing me some more. If someone could give me a solid answer to the below questions regarding what is allowed on the iOS or what would get rejected I would be really grateful.
I've seen posts and sites say that you cannot create bundles on the iOS. Does this also apply to bundles with only images in them?
Is it possible to create a library with .xib files in them? If not then how would one go about including one if custom frameworks are not allowed?
Does using a xCode dynamic library put my application for grounds of rejection (ex. libxml2.dylib)?
Apologies if this is too general or mentioned multiple times, but this whole library and what is allowed and what isn't allowed just doesn't seem to be very clear for me. What I am trying to do is to create some apps and perhaps include some controls that I frequently use in some sort of library or bundle, but I would like to know my limitations before moving further.
1.: No, you cannot create any framework even if it contains images only, as you can't write to the root partition of the iOS filesystem (the part where /System/Library/Frameworks resides).
Of course, if jailbreaking is an option, then all this stuff becomes invalid. You do what you want with a jailbroken phone, so you can create frameworks, add libraries to the filesystem etc.
2.: Yes, it is possible to create a library with XIB/NIB files with it, but then you'll need to share both the source or a static library built from the sources AND the XIB files and guide the other developers to do so in order iOS to correctly handle your library and be able to build the UI from the InterfaceBuilder files.
3.: No, because those libraries are already on the iPhone, you don't have to hack it to get them on the filesystem. libxml2, libsqlite3, etc. are allowed and can be used in any AppStore app.
Related
I am building an iPhone app that requires preloaded content. This content is presented so that it tests the user's knowledge, but is not modified by the user. The content consists of proprietary image files and pdf files.
From what I understand, the best practice would be to store this in the app's Library or Documents directories (please inform if this assumption is not correct). In a future version of the app I might want to upload additional (not replacement) content via API, but this is not part of the initial version.
I have seen many posts and tutorials regarding obtaining paths to the Documents and Library directories of an app, and reading/writing to them. This is all good and useful, but not what I am looking for here.
I would like to preload the content into the Documents and/or Library directories, for the simulator initially, to test app in simulator; and ultimately to the release version. I would have thought this would be possible to do from XCode without writing code.
I have not been able to find a solution to this on Stack Overflow or other places on the net. Any pointers, links, solutions are welcome. I am using XCode 10.3 with Swift 4.2.
See the File System Programming Guide: File System Basics, which shows us:
The “data container” (including the Documents and the various Library folders) is for content generated/saved by the app. When, in Xcode, you mark resources as being part of the target, that becomes part of the bundle, and your app can retrieve it from there at runtime.
Theoretically, yes, you could copy data from the bundle to the Documents and/or Library folders, but, yes, you would have do that programmatically. It seems a bit wasteful to have two copies of these resources on the device, but you can do whatever you want. Generally, though, resources included in the bundle would just be be opened directly from there at runtime, not copying it to the data container (except for those cases where you would need to change it, because bundle contents are read-only).
FYI, for additional information regarding the file system, see the iOS Storage Best Practices video.
My goal is to build a swift iOS framework which uses two other frameworks (included as separate projects) and which shouldn't reveal the source code after built.
Is there some text/guide/documentation which would explain and navigate me through the process of building such a framework properly and correctly?
I built framework with aggregate target adding and linking frameworks on which my custom framework is dependent using run script as indicated here. I was able to add built of my custom framework to my custom app, together with other two dependencies (again as a separate projects), and run it on the device. However, I am not convinced by the correctness of my custom framework built.
Moreover, I was not able to upload the archive to the Appstore due to the various errors of "Unsupported architectures...", "CFBundleIdentifier Collision...", "Invalid Bundle...", "Invalid Binary" and so on. After sorting these errors out according to the various stackoverflow answers and installing the app from the TestFlight, the app crashed after launch and wasn't working at all.
I was checking various blog posts, stackoverflow questions/answers and Apple Framework Programming Guide but nothing gave me comprehensive understanding on building custom framework under conditions described above.
Everything I did was just following step-by-step tutorials without explanation of the purpose of the steps. I am sure I am missing the basics. Could you please help me and give me some guides?
I can understand you frustration. I, a while ago too searched probably for many documents on how to write a framework correctly but like you I also didn't find anything really that satisfying. From my own experiences I can give a couple of advices.
NO External Libraries
In my opinion DO NOT use external libraries in your own framework. I don't really know what your frameworks purpose is but most of the stuff you want to do can be done without using external libraries. Depending on other libraries is not a good idea especially if its a framework you are working on. Anytime these libraries get updated or even worse if they don't you will have to wait for them to be updated or find another library.So rather than this happening later on I think its better if you do it from the start. So loose the external libraries.
Universal Framework Binary
Second one is pretty easy. Generating a universal framework. I suggest you don't use a script. Most of the scripts I found were either outdated or they didn't work at all. Later on I found out that actually it was pretty easy to generate one on your own. You can do this by building your project once for a real device and one for the simulator.Then you can generate a universal binary by using the command lipo -create "Your simulator executable path" "your iOS device executable path" -output "your framework name". What this does is that it combines your two executable files and generates a universal one. Then you can just go and copy your simulator documents from the modules file and paste them in you iphoneos modules file. I am going to share a link were you can go through the walkthrough yourself. https://medium.com/wireless-registry-engineering/create-a-universal-fat-swift-framework-b7409bbfa18f
Use Objective-C(If you can)
This one is bit of a tricky one unless you know objective-c. What I would recommend is that you implement your framework using Objective-C and writing a swift wrapper around it. I would not have said this if you were creating an iOS app but in case of a framework I still think you should go for objective-c. This is because Objective-c has been around for over 30 years and most of the very old apps are in objective-c. If you want your framework to easily be used by older apps coded in objective-c I recommend you go with it. I have read tons of posts on how people have problems trying to use frameworks written in swift in their objective-c apps. Swift will be the first and probably only choice in the near future but not just yet. On the plus side if you still haven't you will have learnt Objective-C which will give definitely give you a better understanding on how things work. It will be challenging but I promise you it will be worth your while .I have a good read on this which you can checkout yourself. https://academy.realm.io/posts/altconf-conrad-kramer-writing-iOS-sdk/
Naming Conventions
This is a pretty straight forward one. I suggest you stick to apples naming conventions. This is because you will be sharing your code this time and people will look for familiarity when trying to integrate your framework. This will make your code easier to understand. You can check out these two links for more info.https://github.com/raywenderlich/objective-c-style-guide (obj-c) https://github.com/raywenderlich/swift-style-guide (swift)
Access Control
This in my opinion is an important one. When working on you framework think before you implement a class or a function. Consider if you would like someone else to be able to use that part of your code. You may want to limit the user while they use your framework and correct access control is the way to do it. You can easily guide the users so the users do exactly what you want them to do with your framework.
Document Your Code
This is a must if you want your framework be a professional one. You should be documenting every function and variable the user will use. Documenting and explaining what your code does makes a lot of peoples lives easy. You don't one anyone trying to understand what your code does for half an hour while you could have easily written a small explanation for what the parameters do and one that function or variable should be used for.
Test Your Code
Last but not least do write tests for your code. This does take some time but it assures you that your code works the way it should.
Look at other good frameworks
You should definitely checkout other open source libraries and look at what they have done. Usually there is no point in reinventing the wheel unless you are doing something absolutely different but even then there are very familiar ways to do things. I can suggest you check out the mantle sdk(https://github.com/Mantle/Mantle). Another one is the very popular Alamofire sdk(https://github.com/Alamofire/Alamofire) and also the Realm sdk(https://github.com/realm/realm-cocoa). These are good examples of frameworks. Take a look at them. Look how they have done things. It will give you an insight on how your framework should look like.
I know all of these points may also be valid if you were writing an app but what makes these a must is the fact that you will be sharing your code with others. You may manage by not doing some of these while implementing an app but for a framework things do change a little bit. It is always a pleasure to work with easy to use frameworks which make coding a pleasure. These types of small things will make your framework preferable. Happy coding.
I think I just must be stupid.
I'm having a lot trouble understanding very basic things concerning frameworks in Xcode/iOs/Swift. While I've certainly gotten some things to work, I've gotten more and more confused about what I'm actually doing. And the documentation on the web just confuses me more.
When I see discussions about how to import particular frameworks (e.g. https://github.com/danielgindi/Charts is the library I'm playing with, but I've seen this pattern repeated in other libraries) they seem to always tell me include the Xcode project file as a child project of my project, in addition to linking things as an embedded binary. This confuses me. Is it not possible to link an already compiled framework to my project without including all the source code of the project?
That is, can't I just take a library.framework file, and add it to my embedded libraries list and be done with it?
In the frameworks I've played with (again https://github.com/danielgindi/Charts is my primary example, but this is true in many others I've played with) I can't seem to use the framework without Carthage or CocoaPods. For me at this stage, that is just confusing... I accept that they are useful tools to automate a difficult process, but I'd really like to understand what that process actually is before I let a tool automate it for me. As I search the web I just seem to always be led back to these tools as being the correct way to do things.
So here are my questions.
If I find a framework library on the web... do I need its source code or can I somehow just link to a compiled version of the framework?
In my reading, it seems that libraries made with Swift are somehow second-class citizens because Swift is a newer thing. Is that still the case? (The articles I read about this seems to date from 2014-2015).
Is there are good place to understand how Apple expects me to add a framework to a project, without using CocoaPods or Carthage?
No need to add source code. Just add the framework to Target ->
General -> Linked Framework and Libraries -> Tap on + and select
your framework.
In my opinion, many new libraries are being written is Swift. So you won't be left behind for using swift.
Apple has documentation about adding frameworks to XCode. But I would suggest to use Cocoapods , as its easy to manage libraries.
Cheers :)
I am intern student who working mobile applications on swift. I created an app for company and I need to embed my app to other partner firm's app. I look some solutions on stackoverflow but they were not clear, Should I use target file? How to embed one app to another app?
Thanks for all help!!
Embedding one app to another isn't quiet right definition. What you are looking for is a Dynamic Framework. You can add a new Dynamic Framework target to your partner's app and move all the functionality and resources you need from your app.
https://developer.apple.com/library/content/technotes/tn2435/_index.html
A framework is a hierarchical directory that encapsulates a dynamic library, header files, and resources, such as storyboards, image files, and localized strings, into a single package. Apps using frameworks need to embed the framework in the app's bundle.
In case if you only want to allow the user to navigate from one app to another, you should use iOS Deep Linking mechanism. There are many third party, ready to use solutions for that, like Branch.
https://branch.io/
This can be usefull as well:
https://developer.apple.com/ios/universal-links/
This can be accomplished by defining a URL schema for your app so that the partner's app can point to.
Here is a tutorial that you need
http://www.brianjcoleman.com/tutorial-deep-linking-in-swift/
I tried to get answer to my question searching among other questions already answered but I did not.
Actual, my question is very simple:
I am trying to integrate third party frameworks to support Ads in my iOS app (AdMob by Google e MoPub). What I can see is that these framework are really huge (>10MB each one). So, I guess the final app size will be very large, also for a trivial app. How can I handle this. I think this is a common situation. Am I missing something in integrating third party frameworks? How do you handle Ads integration in your apps? If you want to have AdMob and you download the latest GoogleMobileAdsSdkiOS-6.12.2, it weighs 13.4MB!
I hope my question is clear enough.
Wait for answers, thank you very much.
Have you tried to make a Release build (e.g., by using the Archive command) of an app that links those frameworks and check the final size?
When the app is built for release, all debug information and other symbols that are required for linking are stripped out, so the binary size will shrink a lot, usually.
Be assured that a release build will be much smaller than a debug build and that the debug build will be smaller than the sum of the individual binaries that you are linking together. You could go, in specific cases I am thinking of, from 200MB pre-link to 2MB after linking in release mode. Generally speaking, unless you have many images or other kind of media bundled with a library, the size will not be a great concern (compiled code shrinks a whole lot) -- but there is no other way than linking the library and see what the linker comes out with to know the real size...