Lower deployment target about foil HOT 9 CLOSED

@kambala-decapitator Thanks again for opening this issue and discussing with us. 😄

I just tagged a new release and pushed to cocoapods. https://github.com/jessesquires/Foil/releases/tag/1.2.0

(also includes #18 )

from foil.

Property Wrappers was released with iOS 12 / Swift 5.1. I'm not sure if it's possible to run it on older versions.

from foil.

Swift libs are copied to device, of course it's possible.

For verification I've successfully launched demo app on device running iOS 10. Can also do that on iOS 9 later if needed.

from foil.

That's a really old version to commit to maintaining tbh 😬 altho I feel your pain. How about opening up a PR that you can consume so we can also see what cascading effects it has with all the tooling and tests we have around the package?

from foil.

opened #17

from foil.

Hey, thanks @kambala-decapitator 😄

I agree with @basememara's hesitation — iOS 9 is quite old, and I am not willing to officially commit to supporting it.

I think a better solution for you would be to implement a post-install hook in your Podfile that resets the deployment target for Foil.

An example:

post_install do |installer|
  installer.pods_project.targets.each do |target|
    target.build_configurations.each do |config|
      config.build_settings['IPHONEOS_DEPLOYMENT_TARGET'] = '9.0'
    end
  end
end

This resets for all pods, but you could modify to check specifically for Foil.

from foil.

Thanks @jessesquires, I know about such workaround. But I'm working on a library and wanted to add Foil as dependency. The only way to make that work would be maintaining my own fork with lower deployment target(s) then.

Not quite sure what is blocking you here: deployment target really matters when using SDK features, but here you're basically using only Swift language features.

from foil.

Not quite sure what is blocking you here

Generally speaking: my concern is simply committing to such a low deployment target and how that affects maintenance. In the future, we may want to take advantage of some iOS 12+ feature. Then, it could be necessary to drop iOS 10 and below, which is a breaking change and not ideal.

For this library specifically: I doubt this would happen. This library is small and unlikely to change much.

but here you're basically using only Swift language features.

And this is a very good point. I think I'm on-board with lowering the targets. I'll also fix #18 -- thank you for that!

from foil.

Thank you very much! :)

Generally speaking: my concern is simply committing to such a low deployment target and how that affects maintenance.

In general I fully agree with you! But when it's simple or even trivial to support older devices, I don't see a reason not to do so :)

In the future, we may want to take advantage of some iOS 12+ feature. Then, it could be necessary to drop iOS 10 and below, which is a breaking change and not ideal.

That's completely fine: at some point of development life cycle requirements and goals may change.

from foil.