Posts

Post marked as solved
2 Replies
0 Views
Fixed the issue. My preview had no soundtrack. Given that the App Store doesn't play sound I saw no point.
Post not yet marked as solved
1 Replies
0 Views
After much experimenting and googling I came across the answer to this. The answer is as follows: <key>UTExportedTypeDeclarations</key> <array> <dict> <key>UTTypeConformsTo</key> <array> <string>public.data</string> </array> <key>UTTypeDescription</key> <string>Writing Shed Data</string> <key>UTTypeIconFiles</key> <array> <string>writingshed.png</string> </array> <key>UTTypeIdentifier</key> <string>www.writing-shed.comuk.Writing-Shed.data</string> <key>UTTypeTagSpecification</key> <dict> <key>public.filename-extension</key> <array> <string>wsd</string> </array> </dict> </dict> </array> <key>UTImportedTypeDeclarations</key> <array> <dict> <key>UTTypeConformsTo</key> <array> <string>public.data</string> </array> <key>UTTypeDescription</key> <string>Writing Shed Data</string> <key>UTTypeIconFiles</key> <array> <string>writingshed.png</string> </array> <key>UTTypeIdentifier</key> <string>www.writing-shed.comuk.Writing-Shed.data</string> <key>UTTypeTagSpecification</key> <dict> <key>public.filename-extension</key> <array> <string>wsd</string> </array> </dict> </dict> </array>
Post marked as solved
1 Replies
0 Views
Just found that the following code does the trick, it just needs amending to include traits:     class func preferredCustomFont(for fontFamily: String, andTextStyle textStyle: UIFont.TextStyle) - UIFont {         let systemFontDescriptor = UIFontDescriptor.preferredFontDescriptor(withTextStyle: textStyle)         let customFontDescriptor = UIFontDescriptor.init(fontAttributes: [             UIFontDescriptor.AttributeName.family: fontFamily,             UIFontDescriptor.AttributeName.size: systemFontDescriptor.pointSize // use the font size of the default dynamic font         ])         // return font of new family with same size as the preferred system font         return UIFont(descriptor: customFontDescriptor, size: 0)     }
Post marked as solved
2 Replies
0 Views
Thanks for your response. I had indeed set an incorrect attribute. One of those stupid mistakes you can stare at for hours and not see!!
Post not yet marked as solved
1 Replies
0 Views
I think the issue might be because I am using custom attributes. It is ok if none are present.
Post marked as solved
10 Replies
0 Views
Thank you for this. No, I’m not used to using pointers in Swift. I try and steer clear of them. As I mentioned earlier these lines aren’t necessary anyway because emumerateAttribute deals with setting it up. Definitely a case of RTM (polite version).
Post marked as solved
10 Replies
0 Views
Ok, so how do you think the code should be written?
Post marked as solved
10 Replies
0 Views
If you look at the documentation for UnsafeMutablePointer you will see that the memory pointed to has to be initialised, not the pointer itself and that the initialize method does this. This is confirmed by declaring stop as a var as in:     func test() {         var stop:UnsafeMutablePointerObjCBool         stop.initialize(to: false)     } This still fails the same way. I will report it as a compiler bug. I think that enumerateAttribute initialises it to false anyway, which is why this code isn't needed in the first place.
Post marked as solved
10 Replies
0 Views
Thanks for the reply. I was mistaking something - there is no need to declare 'stop' outside the closure! That said it doesn't explain the error. The following produces the same error, which I reckon is a compiler bug: import Foundation class Test {     func test() {         let stop:UnsafeMutablePointerObjCBool         stop.initialize(to: false)     } }
Post marked as solved
1 Replies
0 Views
Argh!! I'd unwittingly managed to changed the debugger output option to target output. OK now.
Post not yet marked as solved
10 Replies
0 Views
I was wrong. Moving NavigationViewStyle is a red herring. If you remove it altogether it works. It has no effect in the new position (try changing it to .navigationViewStyle(DoubleColumnNavigationViewStyle()) and you'll see that on iPad). I have managed to get it working in the main view of my App (not this test app), but don't understand why. There seems to be some interaction with .sheet going on. I think it's actually some sort of threading/timing error in SwiftUI. Like I said before, it was working fine in iOS 13.6, so they have clearly screwed something up. Apple, as is often the case, seem totally uninterested.
Post not yet marked as solved
10 Replies
0 Views
Doh! Thanks. They must have changed something because it was working fine for about a year!
Post not yet marked as solved
10 Replies
0 Views
The problem is in IOS 14. It works fine in iOS 13.6.
Post not yet marked as solved
10 Replies
0 Views
What version of IOS are you using?