GhostlyCat

It's not that different between Apple and Microsoft here. If your application model perfectly fits the OS application architecture and you only have to support one single OS, then you can just implement it straight forward in a way that makes OSA support (or COM/OLE) relatively easy. Easy... for an API that got developed 32 years ago and which predates anything that happened with the Internet and the mobile world since then. If you model doesn't fit perfectly, this doesn't mean that it is not possible to implement OSA for it - it just depends how flexible your application architecture is developed. For nearly any non-trivial application this is the case. Don't get me wrong - I don't say that it is "to difficult" or anything like that - I'm just sceptical about marketing drivel about things like this because I know this things in reality and beyond keynote demos. Every time I used it I - at the same time - did marvel the possibilities and curse the peculiarity and fragility of it. Sadly it's a technology that shows its age. It's indeed a dead man walking. And knowing how it works makes clear that it will never will go beyond the Mac and it might even go to the happy hunting ground following so many Apple technologies in the past. Not today. Not tomorrow... but it will happen. Shortcuts is really young, but it is also extremely promising. It's much (!) easier to support (imho). Supporting it would work not only on macOS but also the iPad... which is a _very_ important platform for Affinity. Thats way I think Shortcuts is more important than OSA. Which does not mean that I would oppose OSA capability of macOS Affinity. Again: Don't get me wrong - it is very very useful... Pixelmator Pro... you mean the thing that still isn't on iOS and never was ported to Windows? DevonThink which doesn't support AppleScript (and many other things the Mac version has)? Affinity is a first class citizen on iPad and not some crippled afterthought. As I've written - it is just my opinion that AppleScript and OSA is on the way out and Shortcuts the thing that is getting traction. Of course this is just one view on this topic. I indeed might make sense to support OSA if a big part of Affinity customers are Mac-only. So I'm not opposed to supporting OSA, but I prefer Shortcuts support because I use both: macOS and iPadOS on a daily base.

Yes there are two things going on here with scripting: Scripting within the app (e.g. Macros) and Automation. IMHO (!) supporting AppleScript (or the OSA architecture) is somewhat of hitting a dead horse. It's still used in macOS but not available on even iOS/iPadOS... and very likely never will be, since Apple seems to put their energy into "Shortcuts". OSA isn't the nicest of APIs to support. Don't get me wrong - there is nothing announced yet that would call out for an end of OSA, but from a developers perspective the signs are there. @jbmanos description about object models is a bit misleading... (I might have misunderstood him though) this is NOT something that is "just there" in macOS - it's something you need to actively implement and the application needs to be written to support this. The biggest downside is that this will only work for macOS and not even for iPadOS (not even think about Windows) so it boils down to an economic question... It works in Adobe and MS apps because they are able to throw a hundred developers on their macOS application ports who will implement this even if it will do nothing for non macOS users. In a way Scripting _and_ Automation need an application to be opened up internally in ways to "hook" into its functions. This is the main work that needs to be done. This is something that very likely is not very dependent on the OS used. If this step is done, they can provide e.g. a scripting API using JavaScript by embedding some runtime. An alternative would be to not embed some runtime, but implement a communication/bridging layer... something similar to a "web api" and then using _external_ runtimes to communicate with the App using that communication layer. But if it is done that way, calling a "macro" in the application would then actually start an external process which then communicates back to control the app. All of this are implementation details though. I would see OSA or Shortcuts support as an (important!) "add on" feature over the general scripting/automation support. IMHO shortcuts support would be enough... just ignoring OSA for better use of developer resources. Shortcuts support would enable to use Affinity features to be integrated in workflows written using the macOS and iPadOS shortcuts app. Which definitely would be a nice thing to have. The equivalent in Windows could be something like a COM/OLE interface... a horrible API (even worse than OSA).

Hm... but Affinity Photo is not particularly oriented to 3D and animation as far as I can tell. Photoshop using JavaScript is actually more a reason to use that - because a lot of _image editing_ scripters are used to that. I‘m frontend designer (using Affinity Photo and Designer) and software developer for web and mobile apps. Python doesn’t play any role in that sector - JavaScript is booming though. Another thing: JavaScript generally is booming enormously in the last years. It’s growing hugely in the dev sector and starting with ES2015 has a impressively growing feature set every other year (there is a standards process for that with all the big vendors participating: TC39). There are features like async/await, typed arrays for performance, shared memory & atomics, WebAssembly and so much more. There even are more heavily big vendor maintained JS engines - all of them suitable to be embedded on Desktop and mobile platforms. JavaScriptCore even would be the natural thing to use on Mac and iOS. I understand the Python has some user base in the 3D sector because some of the key players there decided on Python... well... many years ago. But 2018 is not 2008 - the dev sector has changed a lot and I can only stress that it would be a very crude decision to ignore JavaScript as a scripting engine as of today.

Hm... is it only me? I get only the "Signup for Beta" page. I signed up for the beta in march. GC

Its true, that layered TIFF is not just PSD embedded in TIFF but more like a TIFF container implementation of the PSD Format. Technically layered TIFF is practically as native to Photoshop as PSD - there is only one thing missing: Duotone. The same problems of compatibility with PSD account exactly the same to layered TIFF: One point is crucial - there always seems to be a mismatch between _import_ and _export_: 1) Import Import means how much of Photoshops features get recognized in PSD/TIFF and applied to their Affinity counterparts. Think of Grouped layers, layer modes, adjustment layers, smart objects (!) and so on. What about smart objects which use third party Smart filters? 2) Export Most people think PSD/TIF-Support is a symmetric thing - but this is absolutely not the case. Most non-Adobe programs can IMPORT more Photoshop-Features than they can export. This may sound illogical, but exporting from a Program like Affinity to PSD means mapping Affinity-native Features to Photoshops counterparts (which may not exist or not be really accessible). While on import the developers can extend their own Features to cope for Photoshop-Behaviours - this is not possible in the export direction. Conclusion: The route to support layered TIFF besides of PSD in Affinity opens up collaborating with tools of different vendors on some file to some degree (to the degree how good the TIFF/PSD export is - which is limited). The route to embed .aphoto into a TIFF would be perfect for collaboration with RAW workflow software like Capture One or Lightroom. It would be the PERFECT answer to all those questions about a DAM-Module. Those programs only need the merged down version of the image to export or to apply their own non-destructive adjustments on. Editing such a TIFF would just replace the internal .aphoto with a changed one and update the merged down layer. All nondestructive adjustments in the workflow software will then apply to this new merged down image. Since there is a .aphoto in the file, Affinity Photo can actually export any feature that is possible within this suite into it. It would also be possible to open the TIFF in Affinity Designer to add some vector stuff. The downside of this approach is, that any other program would just see the one merged layer and editing it with such a program may destroy the internal .aphoto. I personally really like the "embed .aphoto" approach - this would be the one approach that would allow me to drop my CC subscription. As long as "layered TIFFs" would only offer exporting limited features of Affinity Photo - this would be well... limited. So in an ideal world there would be both options supported. Or even all of those: 1) Flattened TIFF (as now) 2) Layered TIFF, compatibility maximized (as good as possible to Photoshop layered TIFF) 3) Layered TIFF, features maximized (contains .aphoto and a flattened Layer) 4) Layered TIFF complete (combination of 2 and 3 - no flattened Layer) To me only 2 and 3 are really relevant and if I had to choose only one it would be 3. ciao, Jochen

I think scripting will be an important thing for AD. But - sorry rue_mac ;) - Please don't use Python. I know it is still popular with some people, but it is definitely not more powerful than Javascript. With Javascript supported in any Webbrowser and the really big Node.js & NPM boom it is nearly omnipresent now. Perhaps the Idea to create an AppleScript-Interface is the best first option - with OSX Yosemite any AppleScript-App can be scripted using Javascript too.