iOS 7 App Store Submission Failed about sqlite.swift HOT 11 CLOSED

This may be related to the issue here: #44

I'll have to try to come up with a better, supported way of importing the sqlite3 header into Swift (which may end up being one of the ways listed in #44, unfortunately), but in the meantime and in the interest of getting your app submitted ASAP, can you please try the following?

1. Remove SQLite.framework from your target.
2. Link to libsqlite3.dylib instead.
3. Copy the SQLite.swift Swift files into your project and make sure they are included in your target.
4. Add #import <sqlite.h> to your bridging header.

from sqlite.swift.

I followed the steps you mentioned. I got this error this time:

BTW, I submitted the app using C/C++ interface of SQLite inside Objective-C. :(

from sqlite.swift.

@tdgunes Ah, I'll rename those today, as they clash with the Swift module namespace. Sorry for the issues you experienced :(

from sqlite.swift.

Try the latest commit from master if you have the chance.

from sqlite.swift.

Stephen,

I experienced this same error on app store submission using an alternate sqlite3 wrapper. Can you confirm SQLIte.swift will compile with iOS7. If so, can you update your README with explicit considerations/directions for compiling against iOS7.

It looks like a very nice effort.

Thanks,
brian.

from sqlite.swift.

I reverted my app to SQLite.swift version, I tried the latest commit from master and it works! 👍 The binary was validated without any errors.

Well, I have a strict requirement which is the app that I am currently developing must support iOS 7.x, so after reading your commit message "This also allows for iOS 7 support (though I wouldn't recommend it).", it is hard for me to decide whether I should continue developing the app with SQLite.swift or not. I have very few alternatives. All of the other frameworks that I tried for Swift were lacking major features. (For instance, you can not specify custom database in some of them.)

Thanks for your effort and the fix.

from sqlite.swift.

Yeah, would appreciate clarification of this statement:

This also allows for iOS 7 support (though I wouldn't recommend it).

Is it not recommended because:

-some bias against iOS7 vs iOS8 - for obvious reasons

• you did not test with iOS7 personally, and can not cleanly sanction it
• it may experience intermittent behavior
• it will run on iOS8, though not on iOS7 or vice versa

My understanding is the SQLite.swift framework was using a dynamic library supported in iOS8 onwards. And this somehow removes the dynamic library in favor of a static library. Though, I might have this wrong.

Any clarifications much appreciated. I will attempt to integrate today in favor of a current framework I am using which uses the dynamic lib.

from sqlite.swift.

Yeah, would appreciate clarification of this statement:

This also allows for iOS 7 support (though I wouldn't recommend it).

There's nothing that will prevent SQLite.swift from working in iOS 7 other than the fact that the default build instructions are for a framework, and frameworks are not supported in iOS 8. SQLite.swift does not rely on any iOS 8-specific libraries. Before the most recent commit, however, SQLite.swift relied internally on the fact that it would be built as a module (and relied on its own module namespace).

My recommendation for iOS 8 is mostly because I am not using SQLite.swift in iOS 7 projects and thus some maintenance costs may be transferred to you (though I've eaten some of that cost for you already). It will be up to you to inform me when the library no longer works in iOS 7, and you may have to troubleshoot it yourself, or be careful when upgrading to newer versions. The currently published version, however, should work indefinitely (or as long as Apple allows you to submit iOS 7 apps).

from sqlite.swift.

Some clarification if possible might help my understanding.

If in Xcode 6. I specify Deployment target 8.0 in General settings pane.
then select Base SDK 8.2 in Build Settings, this implies I am requiring the user to have 8.0 and above I believe.
Does iOS7 come into play. It seems iTune connect is requiring iOS7 compatibility which I remain unused in my application.

So, for myself I do not intend to run in iOS7. So, do not intend to compile nor test in that release.
Is this accepted/valid, connect compatible?

Just want to make sure I understand, before beginning the port...

On Jan 28, 2015, at 8:12 AM, Stephen Celis [email protected] wrote:

Yeah, would appreciate clarification of this statement:

This also allows for iOS 7 support (though I wouldn't recommend it).

There's nothing that will prevent SQLite.swift from working in iOS 7 other than the fact that the default build instructions are for a framework, and frameworks are not supported in iOS 8. SQLite.swift does not rely on any iOS 8-specific libraries. Before the most recent commit, however, SQLite.swift relied internally on the fact that it would be built as a module (and relied on its own module namespace).

My recommendation for iOS 8 is mostly because I am not using SQLite.swift in iOS 7 projects and thus some maintenance costs may be transferred to you (though I've eaten some of that cost for you already). It will be up to you to inform me when the library no longer works in iOS 7, and you may have to troubleshoot it yourself, or be careful when upgrading to newer versions. The currently published version, however, should work indefinitely (or as long as Apple allows you to submit iOS 7 apps).

—
Reply to this email directly or view it on GitHub #51 (comment).

from sqlite.swift.

@appsird I'm not aware of any iOS 7 requirement as long as your Deployment Target is 8.0.

from sqlite.swift.

Closing this for now. More documentation would be helpful, but the support is there.

from sqlite.swift.