Specify supported locales in a Podfile

[eager]

Our project currently only supports one locale (en), but we use a pod, Appirater, which supports many (26 at this writing). The App Store infers your app’s localizations by looking at the lproj bundles, so our app is listed as supporting all 26 locales, when the majority of our app does not.

Our current plan is to work around this by using a pre_install hook in our Podfile:

pre_install do |installer|
  supported_locales = ['base', 'en']

  installer.pods.each do |pod|
    %x[ find "#{pod.root}" -name '*.lproj' ].split.each do |bundle|
      if (!supported_locales.include?(File.basename(bundle, ".lproj").downcase))
        puts "Removing #{bundle}"
        FileUtils.rm_rf(bundle)
      end
    end
  end
end

This is hacky, and not without issues. For example, because we are modifying the filesystem, rather than the generated Xcode project, if we later add a new localization, the Pods/ directory will need to be deleted and re-installed in order to have access to a pod’s corresponding lproj.

Before resorting to find(1), I looked at InstallerRepresenation to see if it was possible to iterate over the pods and their resources, but it looks like only source files are exposed. Even resources were exposed, it seems like a better approach might be to extend spec.resource_bundles to support localizations, and include supported locales in a more formal manner in the Podfile specification.

[alloy]

Afaik, this is only because Appirater adds all those localization bundles in the root of your app’s bundle. It should not do that. It should have a namespaced resource bundle that contains them and adjust the code accordingly.

As it is now, you can’t even have your own localizations without merging them with those of Appirater, which is bad.

[alloy]

So please raise this issue with the lib author.

[eager]

@alloy Thanks, that makes more sense.

For the curious, I opened arashpayan/appirater#129.

[alloy]

@eager I would leave out the “When using Appirater via CocoaPods” part and the conditional code to support to the current way, because this issue always applies, so it’s never the right thing to do.