Feature/#98 add spm support

[lvnkmn]

Like mentioned in PR #97 I've created a simplified version of the same.

I've tested it and it works.
In order for the project to build I've also had to change the way the default URL handler works. This will cause the user to implement url handling in the app delegate in some cases and is therefore a breaking change and new version will therefore be 10.0.0.

I'll await results from Travis update it's stack if needed.

If all is well at some point. I can do two things:

1. Merge and create a SPM only release tagged 10.0.0
   (since there's no new functionality for cocoapods users, I don't think this should be a problem)
2. Merge and create a SPM only release tagged 10.0.0.prerelease

@Basca what's would be your preference in how to handle the release?

[lvnkmn]

Awesome, tests succeed and checks have passed. @Basca are you ok with me merging this?

[SMillerDev]

This doesn't test the swift build though.

[lvnkmn]

@SMillerDev can you elaborate? In most if not all SPM repo's I've seen this is the way to build. I personally don't see the benefit of changing travis's build setup for this currently.

It's testing the same code, and the SPM part is tested by just using it.

[lvnkmn]

Still not sure what you mean by "test the swift build" by the way. Because it actually does test the build:

and the only code to build is swift.

[SMillerDev]

Right now the SPM integration is only tested when people use it, which will mean that you only know if it works if people report bugs. While you could also have it tested on every commit, since that's what travis-ci is for.

[lvnkmn]

@SMillerDev while you're technically correct, the same counts for issues caused within the 74.5 percent of the code that is not covered by the tests.

From a pragmatic standpoint I'd personally advice against trying to do what you're mentioning. If not, you're going to have to do this for both Cocoapods and SPM introducing less dry code, potentially having to write a new example project as well to fully cover what you're after.

Aside from that, the swift build command you have been using, builds for Mac OS and is therefore not a valid test either.

TLDR; trying to do this for iOS is likely to cause more harm than good, the SPM layer is quite thin, and already tested manually, also there's no changes required on a per release basis.

[SMillerDev]

It's already done for cocoapods and the command I used was modified to work for iOS so it's a small but valid test. It just failed due to the iOS version targeted.

And if you split your code out good enough an argument can be made to test non of it since it's thin and already tested manually.

[lvnkmn]

🎉

Allright, it turned out to be easier than I thought. I see no objections in merging this now. @Basca ?

[lvnkmn]

As for the commits mentioning (temporary):

• pod repo update wasn't needed since all dependencies are known to travis.
• the specs repo did not have to be explicitly added to the podfile

Both commits make the build proces faster.

[SMillerDev]

Looks good to me other than this

[lvnkmn]

Like discussed with @Basca will merge and create a SPM only release 10.0.0