The Art World in Your Pocket or Your Trendy Tech Company's Tote, Artsy's mobile app.

• A colleague ran into a situation where the app would crash on launch. Important to note is that she was also seeing it with other apps, such as LinkedIn.app.
• A restart of her device ‘fixed’ the issue.
• These crashes were not being reported to HockeyApp, meaning it was definitely happening very early in the process.
• Extracting the crash reports directly from the device revealed a dyld error.
• Checking iTunesConnect for crash reports revealed that we had ~80 similar crash reports.

TL;DR

This appears to happen when the device is out of memory, a restart of the device ‘fixes’ it. Presumably this neat trick does so as well.

Info about the errors

Dyld Error Message:
Dyld Message: Library not loaded: @rpath/CocoaLumberjack.framework/CocoaLumberjack
  Referenced from: /var/mobile/Containers/Bundle/Application/D693664B-F6D0-43CB-A839-358E15CAF9E6/Artsy.app/Artsy
  Reason: no suitable image found.  Did find:
    /private/var/mobile/Containers/Bundle/Application/D693664B-F6D0-43CB-A839-358E15CAF9E6/Artsy.app/Frameworks/CocoaLumberjack.framework/CocoaLumberjack:
    mremap_encrypted() => -1, errno=12 for /private/var/mobile/Containers/Bundle/Application/D693664B-F6D0-43CB-A839-358E15CAF9E6/Artsy.app/Frameworks/CocoaLumberjack.framework/CocoaLumberjack

    /private/var/mobile/Containers/Bundle/Application/D693664B-F6D0-43CB-A839-358E15CAF9E6/Artsy.app/Frameworks/CocoaLumberjack.framework/CocoaLumberjack:
    mremap_encrypted() => -1, errno=12 for /private/var/mobile/Containers/Bundle/Application/D693664B-F6D0-43CB-A839-358E15CAF9E6/Artsy.app/Frameworks/CocoaLumberjack.framework/CocoaLumberjack

    /private/var/mobile/Containers/Bundle/Application/D693664B-F6D0-43CB-A839-358E15CAF9E6/Artsy.app/Frameworks/C
  Dyld Version: 370.1

• The error message and codes are always the same.
• The error is not specific to a framework, it happens with various frameworks.
• It appears to have started from iOS 9.1 and up (but that could very well be iOS 9).

Known affected versions

These are the various versions for which we have crash reports.

iOS versions

~/D/dyld crash » ack -h 'OS Version:' **/*.crash | sort | uniq
OS Version:          iOS 9.1 (13B143)
OS Version:          iOS 9.2 (13C75)
OS Version:          iOS 9.2.1 (13D15)
OS Version:          iOS 9.2.1 (13D20)
OS Version:          iOS 9.3 (13E5214d)
OS Version:          iOS 9.3 (13E5225a)

dyld versions

~/D/dyld crash » ack -h 'Dyld Version:' **/*.crash | sort | uniq
  Dyld Version: 370.1
  Dyld Version: 370.6
  Dyld Version: 390.7

Device versions

~/D/dyld crash » ack -h 'Hardware Model:' **/*.crash | sort | uniq
Hardware Model:      iPad3,4
Hardware Model:      iPad4,4
Hardware Model:      iPad4,7
Hardware Model:      iPad5,3
Hardware Model:      iPad5,4
Hardware Model:      iPad6,7
Hardware Model:      iPad6,8
Hardware Model:      iPhone6,1
Hardware Model:      iPhone7,1
Hardware Model:      iPhone7,2
Hardware Model:      iPhone8,1
Hardware Model:      iPhone8,2

Retracing

1. The error is raised here in dyld.
2. Only place where mremap_encrypted could return -1 is here.
3. vn_getpath calls build_path, which in turn has a few possible locations where it could be returning -1:
   • https://github.com/opensource-apple/xnu/blob/977178fc3e01a280624e2095838cb9530763cda9/bsd/vfs/vfs_cache.c#L404
   • https://github.com/opensource-apple/xnu/blob/977178fc3e01a280624e2095838cb9530763cda9/bsd/vfs/vfs_cache.c#L446
   • https://github.com/opensource-apple/xnu/blob/977178fc3e01a280624e2095838cb9530763cda9/bsd/vfs/vfs_cache.c#L509
4. But trying to hunt that further down would take a lot more time, suffice to say that:
   • if mremap_encrypted returns -1, it most likely corresponds to ERESTART: https://github.com/opensource-apple/xnu/blob/2fa84067f6cdeb23267f877ca4fd26201316da1b/bsd/sys/errno.h#L270
   • if errno is 12, it most likely corresponds to ENOMEM: https://github.com/opensource-apple/xnu/blob/2fa84067f6cdeb23267f877ca4fd26201316da1b/bsd/sys/errno.h#L102

Caveats

Alas, the latest dyld sources to be released (at the time of writing) appear to be for version 360.18.

Taking a cursory look at the decompiled code for ImageLoaderMachOCompressed::registerEncryption from a firmware image for iOS 9.2 for iPad3,4, does not appear to have any real changes.

~/t/ios-9.2-iPad3,4 » unzip iPad3,4_9.2_13C75_Restore.ipsw 
Archive:  iPad3,4_9.2_13C75_Restore.ipsw
  inflating: 058-25903-078.dmg       
  inflating: 058-26242-078.dmg       
  inflating: 058-26268-078.dmg
[…]

~/t/ios-9.2-iPad3,4 » ~/Code/ObjectiveC/Debugging/xpwn/dmg/dmg extract 058-26268-078.dmg extracted.dmg -k 7ccd940dfda4b304c87050997e9fd70b458f21b5f3845262d985730b23f41e84aa25dae3
Writing out data..
[…]

~/t/ios-9.2-iPad3,4 » open extracted.dmg
~/t/ios-9.2-iPad3,4 » hopper -e /Volumes/Castlerock13C75.P101OS/usr/lib/dyld

int ImageLoaderMachOCompressed::registerEncryption(encryption_info_command const*, ImageLoader::LinkContext const&)(void * arg0, void * arg1) {
    r0 = arg0;
    r7 = (sp - 0x4 - 0x4 - 0x4 - 0x4 - 0x4) + 0xc;
    sp = sp - 0x4 - 0x4 - 0x4 - 0x4 - 0x4 - 0x4 - 0x4 - 0x4 - 0x4;
    r6 = arg1;
    r8 = r2;
    r4 = r0;
    if (r6 != 0x0) {
            r5 = 0x0;
            do {
                    r2 = *(*r4 + 0xe8);
                    if ((r2)(r4, r5, r2) != 0x0) goto (null);
                    r5 = r5 + 0x1;
            } while (true);
            r1 = r5;
            r2 = *(*r4 + 0x104);
            r0 = (r2)(r4, r1, r2);
            r10 = r6 + 0x8;
            asm{ ldm.w      sl, {r1, r5, sl} };
            r2 = *(r8 + 0xb2);
            r8 = *(r0 + 0x4);
            r6 = r0 + r1;
            r11 = *(r0 + 0x8);
            if (r2 != 0x0) {
                    dyld::log("                      0x%08lX->0x%08lX configured for FairPlay decryption\n");
            }
            r0 = _mremap_encrypted();
            r5 = r0;
            if (r5 != 0x0) {
                    r0 = ___error();
                    r3 = *(r4 + 0x4);
                    r2 = *r0;
                    r1 = r5;
                    r0 = dyld::throwf("mremap_encrypted() => %d, errno=%d for %s\n");
                    // …
            }
    }
    return r0;
}

Conclusion

The crash at launch definitely feels like a very bad experience and I feel like iOS should handle this more gracefully. Maybe show an alert? Will have a think about this and possibly file a radar.

I’m not sure what/if we can do about this. We could probably improve it somewhat by trimming some framework fat from the bundle, but I don’t think these are large anyways.

It would be interesting to know if such failures occurred prior to iOS 9 and if they were labelled differently.

Status

• A couple of radar tickets have already been filed:
  • http://www.openradar.me/radar?id=4952667885404160 (mine)
  • http://www.openradar.me/radar?id=5054516256833536
  • http://www.openradar.me/radar?id=4992459683659776
• A DTS ticket has been filed http://twitter.com/senior/status/707996353964728321
• A guess has been made as to the issue being a jetsam change https://twitter.com/Catfish_Man/status/707955795493687296 (jetsam is the process in which the kernel basically kills apps to free up memory)

This adds Sentry, replacing Hockey for crash reporting, as we're standardising on Sentry across Artsy.

• Adds the Sentry Pod, this is their main supported one, but they do have a non-Swift version too
• Adds new CocoaPods Keys, these can be found in the team 1password
• Adds a new analytical provider (in the app, the one in ARAnayltics is for the old SDK)
• Adds uploading dSYMs to Sentry during deployment

TODO because I want to give it a final look over tomorrow.

Might need to do this too: https://blog.sentry.io/2017/05/01/release-commits.html

All users, trial or not

1. Fair Preview now open--> 12pm local time suggested copy:"Fair X Preview is now open, "x" works now on view
2. Auction now open--> 9pm local time suggested copy: "Auction X is now open, bid on works from Artist Name 1, Artist Name 2, and more"
3. Auction closing soon--> 1 hr before auction closes suggested copy: "Last chance to bid in "Auction X"

Per User, logged in user

1. Outbid at auction--> immediately suggested copy: "You've been outbid in "Auction X" Increase max bid now"
2. New Works by artist you follow--> 10am local time suggested copy: "X" new works by Artist Name 1, Artist Name 2, and more"

This fixes #113.

So I decided to take the if-else block out of ARArtworkRelatedArtworksView and make that a controller concern (still to do). The controller then simply adds the sections for the right context and the view doesn’t need to know about it.

Right now my biggest question is about the sale update, it’s not really clear to me how this is working. I assumed it was so that when you’re looking at an auction lot, it keeps the bids up-to-date? But besides it setting a property (saleArtwork) I don’t see how it would do that. Any hints?

Fixes #367 with a technique discussed on that issue.

Remaining work:

• [x] Write tests.
• [x] Get the share sheet to be present properly (see screenshot below).

It's soooo tiny right at the bottom.

This design does not differ too greatly from what is currently served up by the microgravity view accessed through the YOU VC but in order to increase reliability of the view coming from push it makes sense to make this change.

Included are specs for the view across device types and corresponding zero states. The zero state of this view could have a greatly improved user experience but in the spirit of keeping the scope small we'll stick with this for now.

DEV TODO:

• [x] Switch for native / web
• [x] Basic view - almost there now
• [x] Empty view
• [x] Network model
• [x] Mark as read functionality
• [x] Snapshot tests for VC
• [x] Tests for network model
• [x] Disable rotation
• [x] Fix padding on embedded model VC
• [x] iPad padding and spacing
• [x] Artist linking

There's been a lot of talk in the community about ways to speed up builds, notably thatthinginswift and from bryan irace. These offer one-off ways to check when you think something is slow.

Realistically though, what happens is a long tail of small methods that add up and slowly consume your sanity - till it looks like code Injection is the only way to work productively.

Luckily we have Danger, this PR is adding the ability for us to find out in our CI whether we're introducing code that is taking a long time to compile - either from pods or our app.

Incase you were wondering, Eigen's swift build time wasn't terrible:

~/d/r/Rainforest (master) ⏛  pbpaste | egrep '\.[0-9]ms' | sort -t "." -k 1 -n | tail -10
62.2ms    /Users/orta/dev/ios/apps/eigen/Artsy/View_Controllers/Live_Auctions/Views/LiveAuctionToolbarView.swift:49:10    func setupUsingState(lotState: LotState)
71.1ms    /Users/orta/dev/ios/apps/eigen/Artsy/View_Controllers/Live_Auctions/LiveAuctionLotSetViewController.swift:29:19    @objc override func viewDidLoad()
73.2ms    /Users/orta/dev/ios/apps/eigen/Artsy/Views/Auction/AuctionTitleView.swift:90:10    func titleView() -> UIView
79.0ms    /Users/orta/dev/ios/apps/eigen/Artsy/View_Controllers/Auction/AuctionViewController.swift:123:10    @objc dynamic func setupForSale(saleViewModel: SaleViewModel)
85.2ms    /Users/orta/dev/ios/apps/eigen/Artsy/View_Controllers/Auction/RefinementOptionsViewController+Private.swift:63:10    func stackView() -> ORStackView
86.8ms    /Users/orta/dev/ios/apps/eigen/Artsy/App/ARHockeyFeedbackDelegate.swift:19:10    @objc func showFeedback(image: UIImage? = default)
92.0ms    /Users/orta/dev/ios/apps/eigen/Artsy/Views/Auction/AuctionBannerView.swift:41:18    private func setupViews()
188.3ms    /Users/orta/dev/ios/apps/eigen/Pods/Starscream/Source/WebSocket.swift:528:18    private func processRawMessage(buffer: UnsafePointer<UInt8>, bufferLen: Int)
215.7ms    /Users/orta/dev/ios/apps/eigen/Pods/Starscream/Source/WebSocket.swift:528:18    private func processRawMessage(buffer: UnsafePointer<UInt8>, bufferLen: Int)
551.7ms    /Users/orta/dev/ios/apps/eigen/Artsy/View_Controllers/Auction/AuctionViewController.swift:176:10    @objc dynamic func showRefineTappedAnimated(animated: Bool)

But as mad-eye moody says, Constant Vigilance.

New Dependency

Name: easy-peasy URL: https://github.com/ctrlplusb/easy-peasy

Focus

Easy Peasy is a popular state management solution built on battle tested redux. It provides a modern API and comes with everything one needs to quickly manage inter-component state without needing to write everything from scratch. It has first class TypeScript support, gives us access to the redux middleware system, comes with an immer-based state update patterns, and proves some excellent (and simple) abstractions around observing actions within a system and acting on them without having to write mountains of glue code.

Example from docs:

const store = createStore({
  todos: {
    items: ['Create store', 'Wrap application', 'Use store'],
    add: action((state, payload) => {
      state.items.push(payload)
    })
  }
});

function App() {
  return (
    <StoreProvider store={store}>
      <TodoList />
    </StoreProvider>
  );
}

function TodoList() {
  const todos = useStoreState(state => state.todos.items)
  const add = useStoreActions(actions => actions.todos.add)

  return (
    <div>
      {todos.map((todo, idx) => <div key={idx}>{todo}</div>)}
      <AddTodo onAdd={add} />
    </div>
  )
}

Going forward Eigen would benefit from a consistent, hooks-based batteries-included state management pattern.

Check List

• [x] Have read over the source code, and we can maintain it
• [x] Has had a release in the last year, or looks done and stable

Alternatives

There are quite a few alternatives in the react state management space. We could use redux directly, but the common complaint is that it's too verbose. We could also use react's context directly, but that would mean a lack of consistency, needing to hand-roll perf optimizations, no middleware, etc.

Howdy! So @dblock pointed out that an errant null returned from Metaphysics could still crash the app, so I added some regression tests and got some advice on Twitter about how to deal better with Objective-C JSON parsing. The only parts of our app that parse JSON manually are the ones that use GraphQL (and causality web socket stuff, which is handled by Swift optionals) so it definitely makes sense to test them and make them more robust. I looked for other signs of keypath access that didn't check for NSNull but didn't find any.

I'm sending the PR to the 3.2.5-release branch because Apple will likely require us to submit a fresh binary anyway, and there's no reason that 3.2.5 shouldn't benefit from the better JSON parsing. I'm testing this on-device but my iOS 10 device is totally out of juice; I will mark the PR with an 📱 once it's been tested on-device.

Part of #1035

• [x] UI #1154
• [x] Networking #1156

Coming from an Auction Sale View or from the Live Bidding UI a user needs to access the core information about the sale

coming from

huge oversight on my part omiting this from my initial breakdown of issues for native auction sale views, my apologies

for a reference as to how the sticky labels are supposed to operate on the FAQ please reference this example http://cl.ly/1F263X2q461r

In order to enable non USD auctions, recent PR's in gravity (https://github.com/artsy/gravity/pull/9179 as an example), has added JSON fields to help currency formatting.

So, any field relating to bidding that was of the form _cents (such as estimate_cents), now will also include a display_estimate_dollars field. This field (a string), will include any currency information, as well as proper formatting/rounding.

This makes it easier to actually put on a non USD auction, as clients can become 'dumber' and just render these fields directly, rather than doing a divide by 100 and add a $ sign, type thing.

This is fully backwards-compatible (it's just extra JSON) so no rush, but it would be nice (and I think net code deletion for you guys) to switch to this.

Here's an example of how Force was updated to use it: https://github.com/artsy/force/pull/3334

Will open this issue in Eidolon as well.

Thanks guys! Let me know if you have questions.

Bumps json5 from 2.2.0 to 2.2.2.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

This PR resolves MOPLAT-427

Description

Follow-up to: https://github.com/artsy/eigen/pull/7284 https://github.com/artsy/eigen/pull/7353

Allow releasing specific past versions on Android.

• On uploading a beta to the playstore we will also upload the signed aab to s3
• On promoting a beta to prod we will allow selection/download from s3 and then upload the selected build to the play store

TODO:

• [ ] Test upload is working properly
• [ ] Test promotion is working properly (using alpha lane not prod 😬 )

PR Checklist

• [ ] I tested my changes on iOS / Android.
• [ ] I added screenshots or videos to illustrate my changes.
• [ ] I added Tests and Stories for my changes.
• [ ] I added an app state migration.
• [ ] I hid my changes behind a feature flag.
• [ ] I have prefixed changes that need to be tested during a release QA with [NEEDS EXTERNAL QA] on the changelog.

To the reviewers 👀

• [ ] I would like at least one of the reviewers to run this PR on the simulator or device.

Need help with something? Have a look at our docs, or get in touch with us.

Bumps fast-json-patch from 3.0.0-1 to 3.1.1.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

This PR resolves []

Description

PR Checklist

• [ ] I tested my changes on iOS / Android.
• [ ] I added screenshots or videos to illustrate my changes.
• [ ] I added Tests and Stories for my changes.
• [ ] I added an app state migration.
• [ ] I hid my changes behind a feature flag.
• [ ] I have prefixed changes that need to be tested during a release QA with [NEEDS EXTERNAL QA] on the changelog.

To the reviewers 👀

• [ ] I would like at least one of the reviewers to run this PR on the simulator or device.

Need help with something? Have a look at our docs, or get in touch with us.

This PR resolves []

Description

pairing from mobile office hours @MrSltun @pvinis @brainbicycle

PR Checklist

• [ ] I tested my changes on iOS / Android.
• [ ] I added screenshots or videos to illustrate my changes.
• [ ] I added Tests and Stories for my changes.
• [ ] I added an app state migration.
• [ ] I hid my changes behind a feature flag.
• [ ] I have prefixed changes that need to be tested during a release QA with [NEEDS EXTERNAL QA] on the changelog.

To the reviewers 👀

• [ ] I would like at least one of the reviewers to run this PR on the simulator or device.

Need help with something? Have a look at our docs, or get in touch with us.