Brad Brighton

@CallumIt's a one-off so far.

The app had been running for a while (mostly background as I was working on other things), nothing notable identified about the circumstances. Came back to the machine, up popped the crash reporter. File attached. Affinity Photo 2-2023-03-18-132522.ips

Done, including a fresh version of the crash log. Thank you and let me know please if you need anything else.

So far, this has been reproducible every time (4x as of this post). Crash attached. Original and afphoto files too large to attach but can deliver them if you like. This is a DNG created via VueScan, opened in AP2 and manipulated, saved. Original is linked, still in its original location (different disk), as well as a copy in the same folder as the .afphoto file Steps (when you have the files in question): * open the .afphoto file * select the background layer * click the develop persona button * crash immediately AP 2.0.4 / Mac OS 13.2.1 intel / MBP2018 / 2.9 6-core i9 / Pro Vega 20 4GB Affinity Photo 2-2023-02-25-195228.ips

Given that the app opened normally (for all indications) immediately afterward, it's probably something that will be maddening to attempt to track down. 😄 Also, since I'm mostly in Photo, not Designer, it doesn't mean much one way or the other when I say that there have been no further similar issues.

Posting for documentation purposes since I have the crash report. * Launch 1.9.x (most current, I _think_) * Install and relaunch * On auto-relaunch, crashy * Manual launch after that seemed fine Affinity Designer_2021-08-05-072623_SpamBook2018.crash

Hi @Sean P Sorry, I lost track of this over the week. Here is what I have. -brad 2021_cc_rally.afdesign

The only thing I did that's unusual is dragging the width of the studio to be able to see the dimensions I'm typing in. I had entered values into these fields prior to drag-expanding. The first variation seems to work ok, the second on these slices does not. macOS 11.4 (20F71), AD 1.9.3, MBP 2018 32GB/Radeon Pro Vega 20, external monitor. * moving the AD editor window to the main screen does not make the problem go away * Shrinking the studio does not make the problem change (though I don't know what the exact original width is) * Resetting Studio lost my values in that variation but did not set the editing field back to the full visible width * No, I haven't tried to repro this from a clean start (yet) because I'm trying to get work out under a deadline * However, deleting that variation and adding another for the same slice while the studio is expanded *does* allow proper editing. Screen capture of the oddness attached. Screen Recording 2021-07-17 at 4.16.03 PM.mov

Short version: The vast majority of the style of cruft that you're referring to that made PPC->x86 painful was/is weeded out by the 64bit-only transition well before the Apple Silicon transition. If a developer wants to bring something pre-64bit over, yes, it's going to involve work. If that work has already been done or if the app is natively friendly to the current world anyway, this transition promises to be _relatively_ painless (excepting certain categories like device and/or kernel drivers, etc) which is more a function of the increased security layers that the OS is getting than the drive to Apple Silicon itself.

I'm not a Serif rep however... While the App Store purchase allows you to use the app across multiple iPads, it does not allow you to cross to macOS. You would need to purchase that version separately (either through the Mac App Store or directly from Serif depending on your personal preferences - there are other threads that discuss the differences between the two options).

Also, since Serif are European, your issuing bank may be blocking the charge as possible fraud. You may need to contact your issuer on that.

I have an old bug report on the topic lying around somewhere... my SWAG based on experience is that the tabs are filled in in order of _completion of load_, not _initiation of load_. Larger files in a group will wind up later in the tab order on launch/open group. Predictability among larger files is not high given variations of code performance at the time of file open, available required system resources that may vary depending on the content of the file, and speed of retrieval from underlying storage.

Getting even further off-topic, revision control is notoriously awful with binary files. Bloats the repository since there's not often a meaningful diff between one binary and another that can be applied. You wind up storing the entire file each time. Good when you genuinely need documented reproducibility at a point in time, terrible for most other workflows.

That's only effective if you know where in the history the last notable save was. If you're like me and always (manually for every file, feh) have "save with history" turned on, then you're back to the close-without-saving option only.

Silly questions but the first things to check: are you (1) sure you're logged in at all at the App Store (it's been known to log people out and it not be obvious) and (2) logged in as the Apple ID under which the purchase has been made?