Feature/UI core split

[MartinColja]

I’d love to use this library in my project, but I don’t want to pull in the whole UI package since I’m also supporting macOS. This would enable easier integration with other tools, and people might prefer integration without UI. If the library were split into smaller parts, people could pick and choose what they need.

This is just a draft for now because I still need to implement support for CocoaPods and Carthage. But before I go further, I want to see what you think about this idea.

[krzysztofzablocki]

@MartinColja I love it

[MartinColja]

@krzysztofzablocki sorry for taking so long. I've only worked with SPM so far, so it took me a bit to figure everything out. 😅

Cocoapods

I decided to create two .podspec files instead of having two subspecs. I wanted to set this up so that Cocoapods would generate either just one framework for core or two frameworks where one would depend on the other. Alternatively, I could have used subspecs to filter out which files were included in the framework based on what the user wanted. However, the approach I ended up using is more similar to how SPM does it.

Carthage

To support Carthage, I created a new .xcodeproj for core and a new .xcworkspace for both. Unfortunately, when using Carthage, I wasn't able to configure the project to be visible from Objective-C. It would surprise me if something like that wasn't possible, but I'm just not quite sure how to get there.

Also, I wasn't able to add this framework as a dependency with Carthage, so I still think this is an improvement, even though it isn't visible from Objective-C.

Issues

Another thing I wasn't able to achieve was keeping the Objective-C source from breaking after this separation. Because of that, it will be necessary to write @import LifetimeTrackerCore when using it from Objective-C. With Cocoapods, it was relatively simple to achieve this by creating a custom header and a .modulemap, but frustratingly I wasn't able to get SPM to do the same thing. Supposedly, it should be possible to supply a custom .moduleMap to SPM, but I wasn't able to get it to work.

Please let me know if you think these issues are worth this split, and if not, what issues I should address. Also, I'm open to suggestions if you have any ideas on how to fix or work around these issues.

Finally, I don't know if there is any additional housekeeping that I should do before this is ready to be merged. I increased the version in the specs to 1.8.3, but in semver terms, it should be 1.9.3 or even 2.0.0 given the breaking changes in Objective-C.

[jcavar]

Hey @krzysztofzablocki, we wanted to check in with you about this PR.

Is this something you are still interested in?

[krzysztofzablocki]

I like this, I think you can just loose objective c compatibility to make things easier and do major version bump, people can still use old version with objc

[MartinColja]

@krzysztofzablocki that sounds good! Just an fyi regarding timelines, I can make these adjustments after I free up some of my work queue, hopefully by the end of the month

[krzysztofzablocki]

Sounds good