Unity iOS can handle SQLite even with Byte-Code Stripping on.

Unity iOS can handle SQLite even with Byte-Code Stripping on.

There are some things you need however
1)
Copy (...Unity.app/Contents/Frameworks/Mono/lib/mono/unity/Mono.Data.Sqlite.dll) to ([ProjectFolder]/Assets/Plugins/Mono.Data.Sqlite.dll) (If you want to not use the .NET subset use the folder 2.0 instead of unity

2)
Create a file in assets called 'link.xml' and inside that write:

Code:  

      
      

       
       

         
         

          
          <linker>
         
         

         
         

          
          <assembly fullname=
          
          "mscorlib">
         
         

         
         

          
          <type fullname=
          
          "System.Globalization.CultureInfo" preserve=
          
          "all"/>
         
         

         
         

          
          </assembly>
         
         

         
         

          
          </linker>
         
         
      
      

Then you can start including Mono.Data.Sqlite and run under the .NET Subset with Byte Code Stripping on. There are about 5 other required DLLs but they should manually include. If not every time you see an error about a DLL not found put it in plugins from the same Unity.app folder.

Edit: The extra DLLs that should be added implicitly from the Unity Folder: System.Data, System.Core, System.Transactions, System.Xml.

So far it's been working for us like a charm for months.

问： Can you explain some more about what the purpose is for that link.xml file?

回答：

That part is for using ByteCode Stripping. Link.xml lists all classes that are not allowed to be stripped, even if they are not referenced. Mono.Data.SQLite.dll references Globalization from native code, and this tricks the byte code stripper into thinking it's not used and removing it from the build causing SQLite to work in editor but fail after stripping. 

In short, that file is telling the bytecode stripper not to strip System.Globalization.CultureInfo from mscorlib.dll, even if it can't figure out who is referencing it.

As far as the flying meat database, I've got no idea what that is. You can go with an ObjC implementation but a lack of functional C++ to C# callbacks, as well as a need to run many types through the marshaller before being able to properly read them in C# means it could end up potentially quite clunky. You may have much better success than I did, but my attempts at making a C SQLite plugin and using that turned out much, much worse than the C# SQLite plugin (though even that uses C calls under the hood for the actual database work). If you are comfortable in ObjC and can handle most of the processing from within the plugin you could do much better, I just couldn't find a good design that didn't involve some messy hacks to get all the required data back into C#.

Edit: As a correction, there are functional callbacks, but they are not clean, and rely on linking your plugin to lib-iphone.a when running on device, and lib-unity.a when running on mac. Then you can use the C side Mono functions, callback samples are available at their embedding how-to:
www.mono-project.com/Embedding_Mono

You could end up with some very messy function calls within your plugin if you rely solely on that, but it is possible. These don't screw up AOT compiler like FunctionPointerToDelegate does.