Package structure

[maximkrouk]

Lets discuss package structure 🙂

[maximkrouk]

I'm not sure if I should separate Interface and Live implementations for system frameworks, I guess they do not take a long time to compile (actually they are probably just linked, but not compiled at all). Maybe @mbrandonw has some thoughts about it?

[mbrandonw]

If the live implementation compiles quickly, then there is no need to separate. That is usually the case for clients that wrap system frameworks, like core location, core motion, store kit, etc...

[maximkrouk]

I thought that system libraries are dynamic and stored on a device (except of @_alwaysEmitToClient or smth...), so you don't have to compile it (only to link the interface to your target) and this separation is for

1. External dependencies like AnalyticsClient for example which may use Firebase under the hood (improves compile time)
2. Logic separation so you are forced to rely on the interface and keep your code structure clean

But seems like I was wrong 🤡
Anyway, the package is designed to provide separated Interface and Implementation targets, so I guess I'll just keep it as it is

By the way currently I have

• CacheClient (Foundation.NSCache)
• IDFAPermissionsClient (AppTrackingTransparency.ATTrackingManager & AdSupport.ASIdentifierManager)
• KeychainClient (Security)
• NotificationsPermissionsClient (UserNotifications.UNUserNotificationCenter)
• UserDefaultsClient (Foundation.UserDefaults)
• HapticEngineClient (UIKit.UIFeedbackGenerator)

Some of them only rely on Foundation and should be compiled pretty fast (and anyway each target depends on Prelude so Foundation and probably UIKit are involved anyway (gonna fix it soon 🙂)), but I guess keeping the structure consistent might be the reason to keep the separation even for such targets.