The mini-blog

Cocoapods does not offer a simple way to link a framework from a local path, only by using a :http with link to zip archive. Well, I found a workaround for this. Imagine, you have some proprietary binary framework without source code and you want to add it as a pod rather than link it to the project manually. In that case you can create a private pod with a podspec like this:

Pod::Spec.new do |s| s.name = "SuperCoolLibrary" s.version = "0.0.1" s.authors = "" s.summary = "SuperCoolLibrary for iOS" s.license = { type: 'Commercial', text: '© Company' } s.prepare_command = $TMP_PATH/SuperCoolLibrary.zip echo start http ruby -run -ehttpd "$TMP_PATH" -p9000 & PID=$! echo will terminate webserver later (sleep 20 && echo killing webserver && kill $PID) & CMD s.source = { :http => 'http://localhost:9000/SuperCoolLibrary.zip' } s.source_files = "./SuperCoolLibrary.framework/Headers/*.h" s.public_header_files = "./SuperCoolLibrary.framework/Headers/*.h" s.vendored_frameworks = "SuperCoolLibrary.framework" s.platform = :ios, '8.0' s.requires_arc = true end

In prepare_command we create a zip archiveof a binary framework in a temporary directory, start a local webserver and killing it 20 seconds after (enough for cocoapods to "download" a zip).

In one of my projects I needed ffmpeg to be included in the app bundle. I didn't wanted to build it on my own, so I googled for a static compiled binary and, actually, found it. Great, it's working. But not for long, my laziness is my enemy =)

At some point I realized I need ffprobe tool also. So, should I embed ffprobe static build too? No, absolutely not, 60 MB of distribution size? No way, sir.

I need to include ffmpeg+ffprobe+dylibs into my bundle, it's obvious. I, actually, built it with help of guide I mentioned above. But then I thought: what if there is a simplier way for osx developers. I had a ffmpeg installed already by brew. It's incredibly easy to reconfigure it without dealing with make&install ever. What if I could use those binaries in my app? The bad news is those binares were linked against absolute paths.

After some googling, I've found the solution: use install_name_tool to change those absolute paths to @executable_path! With help of otool -L we can get the list of dylibs paths that should be replaced. So, I've made a shell script that does that and viola! My tool uses dynamicly built ffmpeg and ffprobe, problem solved :)

Here is the script (I've made a github gist also, you can thack the changes, if any):

#install ffmpeg if it is not installed (brew list -1 | grep "ffmpeg" >/dev/null) || brew install ffmpeg #update your ffmpeg distribution to the latest version brew outdated ffmpeg || brew upgrade ffmpeg #cleanup the destination folder for file in `ls ffmpeg/*`; do rm -f $file; done; #determine the last local ffmpeg version COPY_FROM_PATH="" for ffmpeg_path in `brew info ffmpeg | grep 'Cellar/ffmpeg/.*\*' | awk -F' ' '{ print $1 }'`; do COPY_FROM_PATH="$(echo $ffmpeg_path)"; done; #copy all the binaries for source in `find $COPY_FROM_PATH/bin -type f`; do cp -v -f $source ./ffmpeg; done; #I need ffprobe and ffmpeg only, so I remove ffserver here. If you need it - comment this line cd ffmpeg && rm -f ffserver && cd .. #replace references to an absolute path with @executable_path #which will allow to run ffmpeg that loads dylibs from the bundle function replace_dlybs() { DYLIBS=`otool -L $1 | grep "/usr/local/Cellar" | awk -F' ' '{print \$1 }'` for dylib in $DYLIBS; do sudo install_name_tool -change $dylib @executable_path/`basename $dylib` $1; done; for dylib in $DYLIBS; do cp -f -n $dylib ./ffmpeg; done; DYLIBS=`otool -L $1 | grep "/usr/local/opt" | awk -F' ' '{print \$1 }'` for dylib in $DYLIBS; do sudo install_name_tool -change $dylib @executable_path/`basename $dylib` $1; done; for dylib in $DYLIBS; do cp -f -n $dylib ./ffmpeg; done; sudo install_name_tool -id @executable_path/`basename $dylib` $1 } #first replace occurences in ffmpeg and ffprobe binaries for file in `ls ffmpeg/*`; do echo replacing dylibs for $file replace_dlybs $file done; #then replace occurrences in all the additional dylibs that were copied in the previous step for file in `ls ffmpeg/*.dylib`; do echo replacing dylibs for $file replace_dlybs $file done;

My usual genstrings script works well for Objective-C projects. So, when I moved to swift in my new projects, my first attempt was a little patch for find call:

find . -name "*.swift" -o -name "*.m" | xargs genstrings -o Base.lproj

This patch works, but then, suddenly, I faced this bug in genstrings which results in this error message:

Bad entry in file ./File.swift (line = 10): Argument is not a literal string.

genstings cannot parse NSLocalizedString calls with more than 2 parameters, like this: NSLocalizedString("Some String", value: "Some Value", comment: "Some Comment") (objective с equivalent is NSLocalizedStringWithDefaultValue).

Okie. Now what? You have 2 options:

Use NSLocalizedString with just 2 parameters

Use the alternatives

So. The first option is definitely not for me. I like a short dot-separated keys, that allows me to group related strings together + get rid of stupid copying of long sentences both to key and the value. There are non-apple alternatives, like swift_genstrings, genstrings2 or even DTLocalizableStringScanner. But I usually try to use as much apple-provided tools as possible.

I came across to another localization helper tool: xliff export/import. This feature was introduced in xcode6, so it’s not that new as one might think. And yes, it can be automated too!

Few experimenting resulted in two scripts for export and import of xliff files. At first sight this might look not that handy as the genstrings script. First you call export script, then edit the file manually and then call import script. But in other hand, this solution gives some benefits over genstrings solution:

You don’t use base Localizable.strings file at all. Why use it, if those strings are already present in the source code? You can keep the translations only.

Export actually grabs all of your existing traslated strings and put them into xliff file, so you will need to edit just a new/changed strings. You would do it later in strings file anyway.

All the xibs and storyboards strings goes into that single file too. No need in extra scripts that syncs new strings from IB with all the strings files. Hurrah!

xliff file is kinda standard for translators, so, in case when you work with external translators team - you won’t need to explain all the rules of translating strings file correctly. You just give them an xliff file and they will return it to you with correct translations.