Fixed Swift 5.2 load issue, which doesn't fire anymore the initial load method

[pmusolino]

Fixes #78

From Xcode 10.4 and Swift 5.2, there is an issue that doesn't allow Wormholy to work correctly since the initial method which uses an extension of UIApplication doesn't work anymore.

The new solution implemented is based on this. This method works like a starter engine for Wormholy. We will call appWillLaunch() method in Swift (under the StarterEngine class), when didFinishLaunchingWithOptions is fired. This is the flow: 1) App Start 2) StarterEngine receive a UIApplicationDidFinishLaunchingNotification 3) The notification fire the appWillLaunch() method under SwiftySelfAwareHelper

Testing

1) Run the demo app from Xcode 10.4 (Swift 5.2) 2) Shake the device or the simulator 3) Make sure that Wormholy appears correctly now.

@kealdishx since you worked on the initial implementation https://github.com/pmusolino/Wormholy/pull/52 of the solution based on the UIApplication extension, I'd like it if you can check if everything continues to work correctly.

[kealdishx]

I think you don't need create class StarterEngine in oc world, because users could encounter symbol conflict in their app because they already have the class StarterEngine. I recommend that you can use the class name starting with Wormholy, such as WormholyStarterEngine. Additionally, you should remove StarterEngine.h file, because it shouldn't seen by users.

[pmusolino]

Thank you @kealdishx for checking the PR. In theory, the name StarterEngine it's not a problem since it should remain visible only within the module. I'll remove the header file.

[pmusolino]

Let me know if now everything sounds good to you @kealdishx. 👍

[kealdishx]

Thank you @kealdishx for checking the PR. In theory, the name StarterEngine it's not a problem since it should remain visible only within the module.

I don't think so. oc and swift are different worlds.In swift world, you are right, because it has namespace concept, different modules can have the class named StarterEngine. However, oc does not have the concept. In the linking phase, all oc classes will register in the global symbol table and each symbol should be unique, otherwise you will get duplicated symbol error. Swift doesn't have the problem, because it uses different symbol mangling mechanism.

Everything seems ok except the issue above.

[pmusolino]

Thanks, @kealdishx for clarifying this aspect. A not related question, but related to your initial PR. Seems that a user and other users that contacted me directly are affected by this issue. Do you have any idea what can be?

[kealdishx]

I need more information, such as a example project which can reproduce the issue. I cannot get enough information from the issue description.Can you or anyone provide one ？

[pmusolino]

I'll try to create a demo project where it's easy to reproduce the issue 👍 thanks @kealdishx!