My app displays vertically scrollable text to the user which could be as short as a single screen or as long as a book chapter: imagine something like an e-book reader which uses scrolling rather than page-turning. A long time ago when development first started, I tried using UITextView, but the size of text that could be handled was quite limited (a figure of 32767 points seems to stick in the memory). Accordingly I came up with a custom solution in which a UIScrollView handled scrolling gestures and a custom UIView rendered just the part of the text that was visible at that time. That works, but it becomes cumbersome to add support for features such as selection handles and loupes. 18 years later, is there a more smoothly integrated way of displaying long scrollable text?

I am giving the user a view onto a selection of database records. There could be a handful of these, there could be 10,000 of them. At present I use a UITableView. Cells are therefore created or recycled on demand. When a cell is created, it is displayed with default "empty" contents and it sends a message to the server to request a record. When the record arrives, the cell is then able to change its own contents so that the record appears on the screen. There are of course various optimisations, such as cancelling a request if the cell goes offscreen before a reply is received; or delaying a request if it looks as if the cell will end up being off the screen once scrolling has stopped. All this happens with fixed-height cells. Accordingly the UITableView has all the data it needs to work out where every one of the 10,000 cells is. I now want to extend this to variable-height cells. That is: cells whose height depends on the content received from the database. Accordingly, when a cell receives its data it may find itself having to change its own size. Is this structure practicable with UITableView?

I am looking at displaying a database record. The layout is designed by the user but typically looks more like an index card than the row of a spreadsheet. There might be 20-30 fields in a record. Multiplying by the number of records that might be on the screen at a time, that could be a lot of fields. Most fields are text, so UITextView is a natural choice. But is UITextView too heavy or expensive to be used in so many copies? I seem to have 3 choices, in ascending order of apparent efficiency and also ascending order of difficulty of implementation: Have one UITextView per field. Have one UIView subclass per field, designed to look like a UITextView but be cheaper. When the user comes to edit, the current field (but no other) can be overlaid with a UITextView to enable editing. Have one UIViewSubclass for the entire record, designed to look like a collection of UITextViews but cheaper (one view per record instead of one view per field). When the user comes to edit, overlay the current field (but no other) with a UITextView to do the editing. I would welcome advice as to how expensive UITextView actually is. Is it in fact so cheap that there is no point in working hard to avoid having many UITextViews?

Moving the minimum OS version from 4 to 9, I see a message "WatchKit Settings Bundles Deprecated". Settings used to be handled by providing a plist which the Watch app on the iPhone would then use to display settings and allow the user to change them. How, nowadays, should we make settings available to the user to be viewed and changed?

Our app displays a calendar of the week ahead. On tapping a date, it offers three pieces of text for that date. These pieces of text can be quite long. What is the best overall architecture? Reading the documentation and watching the videos, it seems to be a NavigationSplitView whose items are the dates, and whose detail is a TabView which in turn contains three TextViews. Is this right?

On iOS:When one receives a file of type .pages by email, Mail displays a large Pages icon and tapping on it opens Pages. (A long-press brings up the more complicated Actions screen).When one receives a file of type .vcf by email, Mail displays a large Contacts icon and tapping on it opens Contacts. (A long-press brings up the more complicated Actions screen).I have my own custom file type, .ripf, and I want to have the same behaviour because that is what my users will expect. Accordingly, in my app's Info.plist I have a CFBundleDocumentTypes dictionary providing a one-element LSItemContentTypes array referring to the name 'com.universalis.ripcard', and a UTExportedTypeDeclarations dictionary associating the UTTypeIdentifier 'com.universalis.ripcard' with a public.filename-extension 'ripf' and a public.mime-type 'text/vnd.universalis.ripcard'. All the other entries in those two dictionaries are present and correct as far as I can tell. Both CFBundleDocumentTypes[0].CFBundleTypeIconFiles and UTExportedTypeDeclarations[0].UTTypeIconFiles contain a list of icon files for the file type.(That rather long paragraph is to avoid boring people by including the entire Info.plist!)Some things do work..ripf files received via AirDrop bring up a suitable "Open with..." message which mentions my app, and tapping the message opens the app..ripf files received as an email attachment display as an icon. But it is the app's icon and not the icon of the file type.BUTTapping on a received file's icon does not open the app, but only opens the generic Actions screen, offering Message, Mail, WhatsApp, Notes, and only then (after the user has scrolled sideways) "Copy to..." my app.Now, the whole apparatus of CFBundleDocumentTypes and UTExportedTypeDeclarations is obscure and under-documented, and indeed the main documenation for the latter has a big warning at the top saying that it is obsolete and not being updated. That doesn't matter so much. What I need to know is:(Less important): How do I get the right file icon?(More important): How do I get my app to open when the icon is tapped, as Pages and Contacts do? There must be a way – unless special cases for those two apps are wired into iOS itself.

My ultimate aim is to be able to prevent Xcode from single-stepping into certain C++ functions - just as it does not single-step into std:: functions. It appears to be possible to arrange this by making a more elaborate version of an LLDB setting such as this: target.process.thread.step-avoid-regexp (regex) = ^std:: It also appears to be possible to put this setting into an "lldbinit" file so that LLDB (within Xcode) picks up the setting automatically when a debugging session starts. What I do not know is this: Where do I put the "lldbinit" file inside my project? What Xcode project or target settings need to be made to tell Xcode where to find my "lldbinit" file and use it?

Our app, Universalis (Apple ID 284942719) plays audio successfully on all versions of iOS up to and including iOS 17. It uses the old MediaPlayer interface because it is targeted at versions all the way down to iOS 12. On iOS 18, it plays audio but CarPlay fails to show the Now Playing screen. Instead, a message box pops up in CarPlay saying "There was a problem loading this content", with an OK button. Nevertheless the audio plays correctly. This has been reported in the wild by a user of iOS 18 with CarPlay. I am also able to reproduce it locally, running the app in Xcode with the CarPlay Simulator, with an iPhone using iOS 18.0 or iOS 18.1. Earlier versions work correctly. Looking at the console log in CarPlay, the following error message appears about 10 seconds before the error message pops up: MSVEntitlementUtilities - Process Universalis PID[1173] - Group: (null) - Entitlement: com.apple.mediaremote.external-artwork-validation - Entitled: NO - Error: (null) The message has an orange background which appears to mean that it does not come directly from NSLog in the app. The message appears immediately after the request handler of MPMediaItemArtwork has been called requesting a 128 x 128 image and has successfully returned a 128x128 UIImage object. This has been reported through Feedback Assistant: Bug report ID is FB15343941 How can we work round this error?

Is there any way to give blind users free access to features that everyone else has to pay for?

I have successfully implemented Universal Links so that a visitor to specific URLs on our site is redirected to one of our apps. It all works well. Alarmingly well, in that it all worked perfectly first time. (I blame the documentation). A question I can't find specifically addressed in the documentation is: what if we have two apps that can both handle a given link? This is in fact our situation. In most cases users will have one or other of the apps installed. The correct behaviour would then be to direct the user to the installed app. In some cases the user will have both apps installed. In that case the ideal behaviour would be to direct the user to what we have defined to be the "main" app. It looks to me as if it is possible to two apps in an apple-app-site-association file, but not having found this in the documentation, I wonder: has anyone on here actually tried this? Did it work as expected?