iOS 7 support about snapkit

[iartem]

+1

[iblacksun]

@eikebartels You can use git submodule, then import Snap classes into project.

[eikebartels]

Yea sure you can do this but does it not make more sense to set the dependency version for cocoa pods to 7 instead of iOS 8?

[robertjpayne]

Cocoapods cannot build Swift libraries for iOS 7 (app store releases) so unfortunately it's not just as simple as making it available for iOS 7 in the Podspec.

[eikebartels]

Ah I see... didn't know that. Thanks for the info

[Heisenbean]

@robertjpayne
so it means we need to drag the sources files into the project?

[robertjpayne]

@Heisenbean pretty much yea, I internally have a build script that can create a static lib from a pure Swift library and while it holds up well in my production apps it's not something I have in a state to release publicly.

It's a safe bet just to include the source files.

[thedamfr]

Cocoapods builds on iOS 7.
I do it right now with Cocoapods 0.37.0
There is a few warning but it goes smoothly.

[robertjpayne]

@thedamfr could you elaborate? AFAIK Cocoapods does not support iOS 7 for projects that include Swift code unless that has changed recently?

[JunqiangTan]

I think it's time for us to pay close attention to the problem. We need stronger cocoapods, come on

[robertjpayne]

@JunqiangTan the problem is that Xcode does not support building static libraries for Swift code and that Dynamic Frameworks are not supported via the App Store on iOS 7.0.

[JunqiangTan]

@robertjpayne If you wrap the SWIFT, the OC, in the final compile time to mix, how？ I'm just a beginner and cocoapods lovers, I thought may be a bit silly, but this is my best answer, hoping to help.

[robertjpayne]

@JunqiangTan You indeed can mush the Object Code files together after Compile to generate a static lib, it's very messy though and very much not supported by Cocoapods or Apple. It's really just not worth the effort.

If you still need to target iOS 7.0 and want to use Swift I strongly recommend you just use submodules and include the source, it's just too unreliable to go another route.

[thedamfr]

@robertjpayne

This is my current Podfile

source 'https://github.com/CocoaPods/Specs.git'

platform :ios, '7.0'

xcodeproj 'Tripndrive'

use_frameworks!

pod "CNPGridMenu"
pod "NGAParallaxMotion"
pod "Alamofire", '~> 1.2'
pod "CryptoSwift"
pod 'SwiftyJSON'
pod 'MagicalRecord'
pod 'GoogleAnalytics'
pod 'KeychainAccess'
pod 'Facebook-iOS-SDK', '~> 3.23.0'
pod 'JGActionSheet'
pod 'JGProgressHUD'
pod 'SnapKit', '~> 0.12.0'
pod 'SHSPhoneComponent'
pod 'SDWebImage', '~>3.7'
pod 'Fabric'
pod 'Crashlytics'

Output for pod install with 0.37.~

pod install
Analyzing dependencies

CocoaPods 0.38.2 is available.
To update use: `sudo gem install cocoapods`

For more information see http://blog.cocoapods.org
and the CHANGELOG for this version http://git.io/BaH8pQ.

Downloading dependencies
Using Alamofire (1.2.3)
Using Bolts (1.2.0)
Using CNPGridMenu (0.2.1)
Installing Crashlytics 3.1.0 (was 3.1.0)
Using CryptoSwift (0.0.10)
Using Fabric (1.2.8)
Using Facebook-iOS-SDK (3.23.2)
Using GoogleAnalytics (3.12.0)
Using JGActionSheet (1.0.4)
Using JGProgressHUD (1.2.7)
Using KeychainAccess (1.2.1)
Using MagicalRecord (2.3.0)
Using NGAParallaxMotion (1.1.0)
Using SDWebImage (3.7.3)
Using SHSPhoneComponent (2.15)
Using SnapKit (0.12.0)
Using SwiftyJSON (2.2.0)
Generating Pods project
Integrating client project

[!] The platform of the target `Pods` (iOS 7.0) may not be compatible with `Alamofire (1.2.3)` which has a minimum requirement of iOS 8.0 - OS X 10.9.

[!] The platform of the target `Pods` (iOS 7.0) may not be compatible with `CryptoSwift (0.0.10)` which has a minimum requirement of iOS 8.0 - OS X 10.9.

[!] The platform of the target `Pods` (iOS 7.0) may not be compatible with `KeychainAccess (1.2.1)` which has a minimum requirement of iOS 8.0 - OS X 10.9.

[!] The platform of the target `Pods` (iOS 7.0) may not be compatible with `SnapKit (0.12.0)` which has a minimum requirement of iOS 8.0 - OS X 10.9.

[!] The platform of the target `Pods` (iOS 7.0) may not be compatible with `SwiftyJSON (2.2.0)` which has a minimum requirement of OS X 10.9 - iOS 8.0.

This is indeed going to build with SDK 8.4
But you are going to hit validation errors when submission to AppStore (not for Crashlytics).
So when I release for AppStore, I bind directly swift files in my project. This makes the build time comes to 40min which is totally not acceptable for Dev, but is okay for Release.
Cocoapods is okay for dev.
Indeed, if I upgrade Cocoapods to 0.38.2, I have an error because platform :ios, '7.0' break your dependency minimumSDK which is explicitly set at 8.0.

But all in all, if your Lib support 7.0, there is no reason that you don't set minSDK to 7.0
Your lib is not responsible of Cocoapods way of building. Your lib support 7.0. The fact that Cocoapods does not support 7.0 for frameworks is not your problem. You ship code, they build.

So my recommandation would be to set minSDK to 7.0 in next PodSpec.

[robertjpayne]

@thedamfr unfortunately the amount of support requests we were getting from users submitting to app store when the deployment step was step to 7.0 just doesn't make it worthwhile.

Likewise with the rest of the libraries you've listed there they are all in the same boat. I'm also not mindful of iOS 7 vs iOS 8 API's anymore so it's best you maintain a sync'd fork of the Podspec and likely the repo as well.

[thedamfr]

:(

[robertjpayne]

@thedamfr I know it's unfortunate but like all the other repo's the tradeoffs are simply not worth it.

[thedamfr]

Yeah ! But like all the other repos, I'm sending gifs of sad cat hoping they fix it :-(