What you encounter when using Swift to build the SDK and DemoApp (Xcode7.3)

The advantage of using Swift to develop the SDK is that the generated SDK does not need to build bridging files for obj-c or Swift calls, because the Swift SDK is packaged with an. h file that is automatically generated by default for OC calls. The. h file is directly import,sdk in the OC call. When Swift is called, import the SDK name.

The whole process of making the SDK is also very simple, the online blog is not much more (mostly based on OC).

With Swift development, you will encounter strange pits! So write this blog for the purpose of sharing the experience of the settlement of these pits.

1. The way the Portfolio works:

SDK development, it is not recommended to direct the SDK when the app development, or each time the export of the SDK is very troublesome. It is recommended to use the SDK Engineering and demo project combination, so that the export is conducive to debugging.

First you create a new framework for project a development SDK, then build a common app project B, and then drag engineering A to Project B, which makes up a project. The next time in the development of the direct use of B engineering development can be.

It is important to note that if you need to use the SDK in B, you need to refer to the Xxx.framework in product a output for B, which needs to be added in the build phases in the demo project of B , such as

(1) Link Binary with Libraries

(2) Embed frameworks

(3) Copy bundle resources (if the framework has a picture, xib, etc., there is a note about the bundle below, etc. will be mentioned)

2. Management of third parties:

In developing the SDK, developers should have a consensus that the three-party source code should not be packaged into their own SDK. For example, I need to use the Mbprogresshud, I put it into the SDK, not only the program will be very large, other people import will also generate a compilation conflict. So it's best to use cocoapods to tell someone else about the three-way library and version number used in the document.

3. Bridging files:

If we need to refer to the OC file in the Swift SDK, we do not need to add a bridging file. Swift's SDK project will automatically generate a Xxxx.h header file (required in a normal app project), and there are 2 steps you need to do:

(1) in. h Import you use the header file to the OC class.

(2) In the headers of the SDK's engineering setup, put. h in public, as follows:

If your previous project used a bridge file, you would change it to the SDK, you need to take the bridge to the file, and then move the contents of the import into the xxxsdk.h.

4. Invocation of the resource file:

If you use the SDK in the image, Xib,storyboard and other resources, in the app maybe we can call directly, such as UIImage (Named: "xxx"), but the normal app will search the project directory by default, this is also known as Mainbundle.

However, in the SDK, the resource files are stored in the form of the engineering directory/xxxsdk.framework/xxx.png, so the method of direct name is absolutely a direct crash.

I have not found the perfect solution to this pit.

(1) The most reasonable way, must be all the resource files, including xib, pictures and so on all add a bundle, but the location of the bundle is also in the SDK, the same awkward can not be found. The workaround is to join Xxxsdk.framework/xxx.bundle to find the bundle before the location of the resource, and then to find the image, but the bundle, which is too junk, is very difficult to use.

(2) a relatively simple, but not very canonical, way to define a global variable let Sourcerooturl = "xxxsdk.framework/", and then add this directory relationship before each call to the resource, than Slice, UIImage (Named: sourcerooturl+ "xxx"), Xib,storyboard also need.

In this regard, I think xcode should be able to introduce a better solution later.

Support for 5.CPU architectures:

This is very pit, Xcode can debug out or release out of the architecture is very single, either the real-machine architecture, or the emulator architecture, but in fact we provide developers with the SDK may be the real machine and simulator two platforms are required.

So we can merge two libraries, use Lipo-create a b-output C (specifically Baidu search lipo-create), " It is important to note that we are merging the XXXSDK files in the xxxsdk.framework, not the entire framework, and merging them into C, we then put in a replacement for a or B "

But there's a hole here, using the SDK developed by Swift, the FRAMEWORK,OC that the simulator and the real machine can call through the lipo-create merge, but Swift's engineering lack can only call 1 of them, probably and this merger is not very canonical.

This, the official does not provide a more direct point of the method?

Then, on the armv7s architecture (IPhone5 only), Xcode is not supported by default, so if one of your third parties does not support armv7s, your SDK will not support it, and the app will not support it.

6. Problem with duplicate name:

The SDK's startup class and SDK name are not named the same. Or you'll regret it.

7. Delete the framework after the residue problem

Sometimes you may have already removed the SDK from the factory, but the compile time still does not pass, even when the operation appears not to find XXXSDK.

Why? Because Xcode is so stupid *. You've moved the SDK, but you've added target,link with Libraries,bundle and so on before the target framework, and then a run, or try to load the previous framework, it crashed, really silly.

8. Inexplicable collapse, and inexplicable good

I feel that the invisibility bug of Xcode is already very much, especially when combined with storyboard or xib, the bug is more than one order of magnitude.

So this is also a lot of people suggest less use the interface Editor to do the app, and sometimes it is inexplicably wrong.

However, you may restart the computer, close Xcode, or clean up, perhaps no problem at all.

So if there's a bug that has a few hours of confidence that it can't be a problem, you might want to restart the clean up--restart Xcode--and restart the computer.

What you encounter when using Swift to build the SDK and DemoApp (Xcode7.3)