I use SQLite with some custom extensions + ICU (+ some small additions to enable loading minimized ICU dat files) since almost 3 years in all our companies' iOS projects. I came across a posting once on StackOverflow with somebody saying he got a rejection - but this was never the case for us and we deliver like 3 apps to the store per month.
So, just don¹t include and link against the .dylib. And then there should to my knowledge nothing stand in the way to link and roll your own ICU, neither from legal nor Apple perspective. To be on the save side, change the ICU version number for your own ICU build. ICU functions get a postfix (which is resolved when you include the headers of a particular build). So for example u_something() is resolved to u_something_53(). In practice it is however quite unlikely that these will collide, since Apple (like also other distributions) is rather conservative and doesn¹t use the very latest version. But be on the save side here and just change it. I¹ve wrapped my SQLite build into an iOS fake framework. I need to say however that embedding ICU into SQLite was quite tedious. I ended up stripping ICU to the minimum required by SQLite, needed to fiddle with defines and also had to alter a few lines of code (it becomes obvious if you try to build what needs to be changed - like a Point type that conflicts with some included header file on iOS). I unfortunately can¹t give you this project, as it belongs to the company I work for. But I can help you to create your own one. Ben Am 16.06.14 01:08 schrieb "Josh Wilson" unter <neozenith....@gmail.com>: >This might seem like a dumb question but I am getting conflicting >information from web sources. > >https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1218086. >html > >I'm trying to enable unicode61 tokenizer for a build on iOS. Apple frowns >upon including your own libicu since they include their own >libicucore.dylib and restrict access to how it is used purely through >their >NSString APIs. > >The above link suggests I can simply compile sqlite with >-DSQLITE_ENABLE_FTS4_UNICODE61 >but not needing -DSQLITE_ENABLE_ICU. > >I have tried this with v3.8.5 and get errors that the unicode61 tokenizer >is not recognised. Which makes sense to me, since presumably sqlite relies >on ICU for it's definition of 'what is unicode' (as it is a moving target >it would seem). > >So is it possible to have an ICU-less build that allows the unicode61 >tokenizer? > >Or should I look at writing a custom tokenizer that hooks into the allowed >NSString API? > >Kind Regards >-- > >Josh Wilson >_______________________________________________ >sqlite-users mailing list >sqlite-users@sqlite.org >http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users