We build ours using archive before lipo-ing and we don’t have to strip the simulator bits out.
> On Apr 5, 2018, at 4:03 PM, Cody Garvin <c...@servalsoft.com> wrote: > > EXTERNAL > > We send them one that is lipod then give them a build phase script that > strips the opposite architecture out. A bit easier than switching frameworks > that could potentially have different versions and avoid separate targets to > add the different architecture library to. Let me know if you’d like our > script. > > Please excuse mobile typos > >> On Apr 5, 2018, at 12:04 PM, Alex Zavatone <z...@mac.com> wrote: >> >> >>> On Apr 5, 2018, at 1:37 PM, Redler Eyal <e...@mellel.com> wrote: >>> >>> >>>> On 5 Apr 2018, at 17:29, Alex Zavatone <z...@mac.com> wrote: >>>> >>>> >>>>> On Apr 5, 2018, at 4:19 AM, Redler Eyal <e...@mellel.com> wrote: >>>>> >>>>>>> >>>>>>>> 2. (More importantly) It makes the client's binary larger since it >>>>>>>> will have to include our full library, including simulator code. >>>>>>>> (correct me if I'm wrong) >>>>>>> >>>>>>> No, you should ask your client to remove the simulator slice before >>>>>>> submitting to the App Store. >>>>>> >>>>>> This is controlled in the build settings for release builds. Compiled >>>>>> Simulator code is not packaged and should not be packaged in a release >>>>>> build. >>>>> >>>>> My understanding is that the dynamic lib is copied as a resource and not >>>>> processed automatically that way. >>>>> >>>> >>>> >>>> But when it is built, it is built as Release or Debug, unless you have >>>> added other build configurations. When Archive is selected, that uses >>>> Release. >>>> >>>> Why would a Simulator i386 architecture be used in a release build? You >>>> can check the configuration and see if that architecture is even there in >>>> the build config. >>> >>> Because we are building an SDK - for other developers that need to be able >>> to run their app, with our SDK, in the simulator. >>> >> >> I have done this twice. If you need to distribute a version of the >> framework witth simulator code in it, then you will need another build >> configuration that does include this. Duplicate a build config and add >> i386. If you need to strip debug symbols or add debug symbols, then >> duplicate another build configuration and add or remove those settings. >> >> Create as many build configurations as needed by duplicating and modifying >> what is needed. Clearly document this for your customer. Build them what >> they need and send them all the frameworks to link to. Yes, it’s hard. >> >> - Alex Zavatone >> _______________________________________________ >> >> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) >> >> Please do not post admin requests or moderator comments to the list. >> Contact the moderators at cocoa-dev-admins(at)lists.apple.com >> >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/cocoa-dev/cody%40servalsoft.com >> >> This email sent to c...@servalsoft.com > > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/jim.adams%40sas.com > > This email sent to jim.ad...@sas.com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
