Construct and manage graphical, event-driven user interfaces for iOS or tvOS apps using UIKit.

UIKit Documentation

Posts under UIKit subtopic

Post

Replies

Boosts

Views

Activity

Issue with iOS26 and hiding UITabBar
I have a strange issue for iOS26. I have a UITabBarController at the root view of the app, but on certain actions, I want to hide it temporarily, and then have some options where the user can press a button which display some options using UIAlertController. It used to work fine before, but with iOS26, when the UIAlertController is presented, the tab bar (which is hidden by setting the ‘frame’) suddenly pops back into view automatically, when I don't want it to. Here's an example that reproduces the issue: class TestTableViewController: UITableViewController { private var isEditMode: Bool = false override func viewDidLoad() { super.viewDidLoad() // Do any additional setup after loading the view. self.navigationItem.leftBarButtonItem = UIBarButtonItem(title: "Change", style: .plain, target: self, action: #selector(changeMode)) } @objc func changeMode() { print("change mode called") if isEditMode == false { isEditMode = true // hide tab bar setEditingBarVisible(true, animated: true) self.navigationItem.rightBarButtonItem = UIBarButtonItem(title: "Action", style: .plain, target: self, action: #selector(showActionsList)) } else { isEditMode = false // show tab bar setEditingBarVisible(false, animated: true) self.navigationItem.rightBarButtonItem = nil } } @objc func showActionsList() { let alert = UIAlertController(title: "Action", message: "showing message", preferredStyle: .actionSheet) alert.addAction(UIAlertAction.init(title: "Cancel", style: .cancel, handler: nil)) self.present(alert, animated: true, completion: nil) } @objc func setEditingBarVisible(_ visible: Bool, animated: Bool) { guard let tabBar = tabBarController?.tabBar else { return } let performChanges = { // Slide the tab bar off/on screen by adjusting its frame’s y. // This is safe because UITabBar is frame-managed, not Auto Layout constrained. var frame = tabBar.frame let height = frame.size.height if visible { // push it down if not already if frame.origin.y < self.view.bounds.height { frame.origin.y = self.view.bounds.height + self.view.safeAreaInsets.bottom } // Give our content its full height back (remove bottom safe-area padding that tab bar created) self.additionalSafeAreaInsets.bottom = 0 } else { // bring it back to its normal spot frame.origin.y = self.view.bounds.height - height // Re-apply bottom safe-area so content clears the tab bar again self.additionalSafeAreaInsets.bottom = height } tabBar.frame = frame // Ensure layout updates during animation self.tabBarController?.view.layoutIfNeeded() self.view.layoutIfNeeded() } if animated { UIView.animate(withDuration: 0.28, delay: 0, options: [.curveEaseInOut]) { performChanges() } } else { performChanges() } } } I have a bar button called 'Change', and selecting it should hide/show the UITabBar at the bottom, and show/hide a different bar button called 'Action'. Selecting the 'Action' button shows an alert. With iOS26, with the tab bar moved out of view, when the 'Action' button is called, the alert shows but the tab bar automatically moves into view as well. Is this a known issue? Any workaround for it? I filed FB19954757 just in case.
Topic: UI Frameworks SubTopic: UIKit
0
0
122
1w
[NSBitmapImageRep imageRepsWithContentsOfFile] error with HDR
[NSBitmapImageRep imageRepsWithContentsOfFile] is returning empty/solid black bitmaps for some image files with HDR on macOS Tahoe beta. I opened an Apple feedback report but curious if anyone else is seeing this. Errors thrown in the debugger are: IIOApplyHDRGainMap:351: FlexGTC headroom (4.0) doesn't match target headroom (1.0) +[HDRImage getGainMapVersionMajor:minor:fromMetadata:]:417: Failed to get metadata tag: HDRGainMap:HDRGainMapVersion +[HDRImage getGainMapHeadroom:fromMetadata:]:443: Failed to read gain map version info: <CGImageMetadata 0x9fc013700> ( iio:hasXMP = True ) This function call has worked reliable for many years before the Tahoe beta.
Topic: UI Frameworks SubTopic: UIKit
3
0
113
1w
Floating keyboard issues on iPadOS 26
Observed on iPadOS 26 b8 in apps built with current SDK: Floating keyboard lacks corner mask Floating key blue highlight not aligned with its background Invoking floating keyboard can result in “ghost” full-sized keyboard appearing at bottom of screen Swipe-dismissing floating keyboard can result in it bouncing back up, again with ghost keyboard appearing Touching globe key can produce menus truncated/obscured by ghost keyboard Ghost keyboard can remain visible even after backgrounding the app (Some of these issues may be limited to non-English keyboards) FB19951605
Topic: UI Frameworks SubTopic: UIKit
0
0
121
1w
UITabBarController not allowing scroll content behind it
I am trying out iOS26 with my existing app. I have a UITabBarController which is set to the main window's rootViewController, and I setup my UITabBar viewControllers programmatically. The first tab's root view has a UITableView with 100s of rows. When I build and run with the new Xcode, the app has the iOS26 look, but the table view doesn't seem to scroll behind the tab bar. The tab bar seems to have a hard edge and the content doesn't show through behind that. I have tried setting up the UITabBarController with the UITab items from iOS18 as well, but that doesn't help either. If I build a new project using the Xcode template, with storyboards, it works as expected and table view content shows through the UITabBar. What could be causing this? Is there something I need to configure to get the correct effect in iOS26? -- Figure it out: I needed to pin the bottomAnchor of the view controller to view's bottomAnchor (not safeAreaLayoutGuide.bottomAnchor)
Topic: UI Frameworks SubTopic: UIKit
0
0
159
1w
UICollectionView list: leading swipe overshoots in expanded split view for .plain/.grouped; .insetGrouped OK (iPadOS 26 b5–b8) [FB19785883]
Hi all, Sharing a reproducible UIKit issue I’m seeing across multiple iPadOS 26 betas, with a tiny sample attached and a short video. Short video https://youtu.be/QekYNnHsfYk Tiny project https://github.com/yoasha/ListSwipeOvershootReproSwift Summary In a UISplitViewController (.doubleColumn), a UICollectionView using list layout shows a large leading-swipe overshoot when the split view is expanded (isCollapsed == false). The cell content translates roughly 3–4× the action width. Repros with appearance = .plain and .grouped Does not repro with .insetGrouped Independent of trailing provider (issue persists when trailing provider is nil) Collapsed split (compact width) behaves correctly Environment Devices: iPad Air (3rd gen), iPadOS 26.0 (23A5326a) → Repro Simulators: iPad Pro 11-inch (M4), iPadOS 26.0 beta 6 → Repro Also tested on device: iPadOS 26 beta 5, 6, 7, 8 Xcode: 26.0 beta 6 (17A5305f) Steps to reproduce Launch the sample; ensure the split is expanded (isCollapsed == false). In the secondary list, set Appearance = Plain (also repros with Grouped). Perform a leading swipe (LTR: swipe right) on any row. Actual: content shifts ~3–4× the action width (overshoot). Expected: content translates exactly the action width. Switch Appearance = InsetGrouped and repeat the leading (swipe right) gesture → correct (no overshoot). Feedback Assistant FB ID: FB19785883 (full report + attachments filed; this forum thread mirrors the repro for wider visibility) Minimal code (core of the sample) If anyone from Apple needs additional traces or a sysdiagnose, I can attach promptly. Thanks! // Secondary column VC (snippet) var cfg = UICollectionLayoutListConfiguration(appearance: .plain) // also .grouped / .insetGrouped cfg.showsSeparators = true cfg.headerMode = .none cfg.leadingSwipeActionsConfigurationProvider = { _ in let read = UIContextualAction(style: .normal, title: "Read") { _,_,done in done(true) } read.backgroundColor = .systemBlue let s = UISwipeActionsConfiguration(actions: [read]) s.performsFirstActionWithFullSwipe = false return s } // Trailing provider can be nil and the bug still repros for leading swipe: cfg.trailingSwipeActionsConfigurationProvider = nil let layout = UICollectionViewCompositionalLayout.list(using: cfg) let collectionView = UICollectionView(frame: view.bounds, collectionViewLayout: layout) // … standard data source with UICollectionViewListCell + UIListContentConfiguration // Split setup (snippet) let split = UISplitViewController(style: .doubleColumn) split.preferredDisplayMode = .oneBesideSecondary split.viewControllers = [ UINavigationController(rootViewController: PrimaryTableViewController()), UINavigationController(rootViewController: SecondaryListViewController()) ]
0
0
90
1w
No large titles margin on iOS 26
I need more time to adapt to the new iOS 26 UI, so I set the "UIDesignRequiresCompatibility" attribute to "Yes." This works, but now all large titles are not aligned with the content. Below you can see an example, but I have the issue with all large titles. All good on iOS 18. Does anyone have an idea why and how can i fix it?
2
1
120
1w
Can we use a class (.self) as the target in addTarget(_:action:for:) for static event handlers?
I am building a centralized event handling system for UIKit controls and gesture recognizers. My current approach registers events using static methods inside a handler class, like this: internal class TWOSInternalCommonEventKerneliOS { internal static func RegisterTouchUpInside(_ pWidget: UIControl) -> Void { pWidget.addTarget( TWOSInternalCommonEventKerneliOS.self, action: #selector(TWOSInternalCommonEventKerneliOS.WidgetTouchUpInsideListener(_:)), for: .touchUpInside ) } @objc internal static func WidgetTouchUpInsideListener(_ pWidget: UIView) -> Void { print("WidgetTouchUpInside") } } This works in my testing because the methods are marked @objc and static, but I couldn’t find Apple documentation explicitly confirming whether using ClassName.self (instead of an object instance) is officially supported. Questions: Is this approach (passing ClassName.self as the target) recommended or officially supported by UIKit? If not, what is the safer alternative to achieve a similar pattern, where event registration can remain in static methods but still follow UIKit conventions? Would using a shared singleton instance as the target (e.g., TWOSInternalCommonEventKerneliOS.shared) be the correct approach, or is there a better pattern? Looking for official guidance to avoid undefined behavior in production.
Topic: UI Frameworks SubTopic: UIKit Tags:
1
0
59
1w
Issue with custom keyboard height when toggle inputView in iOS 26 beta.
Issue Description: When toggling between the system keyboard and a custom input view, the keyboard height reported in subsequent keyboard notifications becomes incorrect!!! specifically missing the predictive text/suggestion bar height. Environment: Device: iPhone 11 Expected keyboard height: 346pt Actual reported height: 301pt (missing 45pt suggestion bar) Reproduction Steps: Present system keyboard → Height correctly reported as 346pt Switch to custom input view → Custom view displayed Switch back to system keyboard(no suggestion bar) → Height correctly reported as 301pt Trigger keyboard frame change → Height still incorrectly reported as 301pt despite suggestion bar being visible Expected Behavior: Keyboard height should consistently include the suggestion bar height (346pt total). Actual Behavior: After switching from custom input view, keyboard height excludes suggestion bar height (301pt instead of 346pt). key code private func bindEvents() { customTextField.toggleInputViewSubject.sink { [weak self] isShowingCustomInput in guard let strongSelf = self else { return } if isShowingCustomInput { strongSelf.customTextField.inputView = strongSelf.customInputView strongSelf.customInputView.frame = CGRect(x: 0, y: 0, width: strongSelf.view.frame.size.width, height: strongSelf.storedKeyboardHeight) } else { strongSelf.cusTextField.inputView = nil } strongSelf.customTextField.reloadInputViews() strongSelf.customTextField.becomeFirstResponder() }.store(in: &cancellables) }
Topic: UI Frameworks SubTopic: UIKit Tags:
0
1
89
1w
UICollectionView Drag to edge of screen is not working with Stage Manager
In our app we have a UICollectionView with Drag&Drop functionality enable and collection view is covering the entire screen. When we drag a collection view item to the edge of the screen it does not scroll the UICollectionView instead that our item turns into the app icon and scrolling blocked. It is happening only if Stage Manager is enabled in the device and if Stage Manager is disabled it is working fine. This issue we are facing after iOS 18.6 release, before 18.6 it was working fine i.e, collection view was scrolling to next items when we dragging an item to edge of the screen, similar to the iOS calendar app when we drag an event to edge it starts scrolling the date. And in iOS 26 if we drag an item to edge, Springboard is getting crashed.
1
1
89
1w
UIGraphicsImageRenderer display blank image with iOS 26
Hello, First of all, I've already made a bug report here : https://feedbackassistant.apple.com/feedback/19731998 I'm facing a problem while using UIGraphicsImageRenderer to create an image, that is use to create a UIColor with a pattern via UIColor(patternImage:). It's well displayed for iOS 18.2 and lower, whereas the whole color is blank with iOS 26. -> Please find a sample project linked to the bug report ViewController.swift post that illustrates the issue, in the ViewController.swift file. I'll also link screenshots of the sample app, one built with iOS 18.2 and another with iOS 26.0. Reproduction steps : I create an image with UIGraphicsImageRenderer : let image = UIGraphicsImageRenderer().image { context in // Do anything here } Then I use this image to create a UIColor : UIColor(patternImage: image) I apply this color to the fillColor of a CAShapeLayer : shapeLayer.fillColor = UIColor(patternImage: image) Expected result : Run on iOS 26 and lower and the layer filled with the pattern color is correctly displayed, as it is on iOS 18.2 and lower. Observed result : Run on iOS 26 and the layer is filled with a blank/white color instead of the intended pattern color. Has anyone been facing the problem ? Thanks, Thibault Poujat
Topic: UI Frameworks SubTopic: UIKit Tags:
1
0
49
1w
Change to safe area logic on iOS 26
I have a few view controllers in a large UIKit application that previously started showing content right below the bottom of the top navigation toolbar. When testing the same code on iOS 26, these same views have their content extend under the navigation bar and toolbar. I was able to fix it with: if #available(iOS 26, *, *) { self.edgesForExtendedLayout = [.bottom] } when running on iOS 26. I also fixed one or two places where the main view was anchored to self.view.topAnchor instead of self.view.safeAreaLayoutGuide.topAnchor. Although this seems to work, I wonder if this was an intended change in iOS 26 or just a temporary bug in the beta that will be resolved. Were changes made to the safe area and edgesForExtendedLayout logic in iOS 26? If so, is there a place I can see what the specific changes were, so I know my code is handling it properly? Thanks!
Topic: UI Frameworks SubTopic: UIKit
1
0
223
1w
iOS 26 (beta) Nav Bar Item Image Insets bug
I've noticed that in iOS 26, Navigation Bar Items' Image Insets parameters as set in Xcode are not being read correctly. Specifically, it appears that on iOS 26 beta, negative inset numbers are being read as positive. Feedback report FB19838333 includes a sample project demonstrating this bug.
0
0
129
1w
Compositional Layout's broken `visibleItemsInvalidationHandler`
Hello everybody! TLDR: Issues with visibleItemsInvalidationHandler. Minimal code to reproduce available. I've been working with Compositional Layout for a while now and recently I've found myself needing to implement custom animation based on scroll position of UI elements. Once I found visibleItemsInvalidationHandler it felt like the exact solution that I needed. Once I implement I've found out it doesn't quite behave as you'd expect. To put it simply, it seems like the animations only work if your whole layout does not use .estimated nor .uniformAcrossSiblings. As soon as you use them then the animations will stop working, I've debugged it deeper and it seems like the invalidation context generated by it does not include the indexPath of the cells, which is always included in the version in which it works. Feel free to swap the line 51 with its comment to flip between the working and failing version of it. Playground Example My final question therefore is... Is this the expected behavior? The documentation doesn't give any clues about such behavior and although I've tried relentlessly to find a workaround for this specific hiccup I was not successful with it.
1
0
92
1w
Issue with custom keyboard height when rotating from landscape to portrait in iOS 26 beta.
When using a custom keyboard set via UIResponder.inputView, a gap appears between the text field and the custom keyboard after rotating from portrait to landscape and back to portrait. On a portrait screen, when switching to a custom keyboard: The input field at the top and the custom keyboard below it appear normally, with no empty space in between. When I rotate from portrait to landscape, a gap appears in the middle.
Topic: UI Frameworks SubTopic: UIKit
1
1
83
1w
WKWebView LoadRequest crash on ios 26
Since the ios 26 beta our app is crashing when calling LoadRequest() on the wkwebview class. The app crashes out completely when it occurs even in the debugger, I was able to get a stack trace from our Sentry crash handler. See below It seems that calling LoadRequest from the mainthread fixes the issue but I don't understand why, theres no documentation to suggest this must be done. Any ideas? Below is the stack trace I got from Sentry: WebKit +0x0054e00 WebKit::allDataStores WebKit +0x0bf34f4 WebKit::NetworkProcessProxy::preconnectTo WebKit +0x0acef64 WebKit::WebPageProxy::preconnectTo WebKit +0x0b0d92c WTF::Detail::CallableWrapper::call WebKit +0x0ab6cf8 WebKit::WebPageProxy::maybeInitializeSandboxExtensionHandle WebKit +0x0ab84dc WebKit::WebPageProxy::loadRequestWithNavigationShared WebKit +0x0ab7adc WebKit::WebPageProxy::loadRequest WebKit +0x05d0704 -[WKWebView loadRequest:] Grid3iOS +0x5240944 xamarin_dyn_objc_msgSendSuper In App Grid3iOS +0x187dec4 wrapper_managed_to_native_ObjCRuntime_Messaging_NativeHandle_objc_msgSendSuper_NativeHandle_intptr_intptr_ObjCRuntime_NativeHandle In App Grid3iOS +0x512fac4 Microsoft_iOS_WebKit_WKWebView_LoadRequest_Foundation_NSUrlRequest (WKWebView.g.cs:572)
1
0
50
1w
UIGlassEffect can leave an unusual grey shadow around the view
When adding a glass effect to my UIControl: let effectView = UIVisualEffectView() let glassEffect = UIGlassEffect() glassEffect.isInteractive = true effectView.effect = glassEffect effectView.cornerConfiguration = .capsule() addSubview(effectView) effectView.snp.makeConstraints { $0.edges.equalToSuperview() } effectView.contentView.addSubview(stackView) for subview in effectView.subviews { subview.backgroundColor = .clear } self.effectView = effectView I find that I get this visual effect: These controls are the only view within a UICollectionViewCell. Nothing in the hierarchy of the collectionview to the control has a background color. The grey background only seems to appear when I place the glass effect. Without the glass effect, there is no grey shading.
Topic: UI Frameworks SubTopic: UIKit
3
0
142
2w
TextKit 2 calls NSTextLayoutFragment's draw method too often
The following is verbatim of a feedback report (FB19809442) I submitted, shared here as someone else might be interested to see it (I hate the fact that we can't see each other's feedbacks). On iOS 16, TextKit 2 calls NSTextLayoutFragment's draw(at:in:) method once for the first paragraph, but for every other paragraph, it calls it continuously on every scroll step in the UITextView. (The first paragraph is not cached; its draw is called again when it is about to be displayed again, but then it is again called only once per its lifecycle.) On iOS 17, the behavior is similar; the draw method gets called once for the 1st and 2nd paragraph, and for every other paragraph it again gets called continuously as a user scrolls a UITextView. On iOS 18 (and iOS 26 beta 4), TextKit 2 calls the layout fragment's draw(at:in:) on every scroll step in the UITextView, for all paragraphs. This results in terrible performance. TextKit 2 is promised to bring many performance benefits by utilizing the viewport - a new concept that represents the visible area of a text view, along with a small overscroll. However, having the draw method being constantly called almost negates all the performance benefits that viewport brings. Imagine what could happen if someone needs to add just a bit of logic to that draw method. FPS drops significantly and UX is terribly degraded. I tried optimizing this by only rendering those text line fragments which are in the viewport, by using NSTextViewportLayoutController.viewportBounds and converting NSTextLineFragment.typographicBounds to the viewport-relative coordinate space (i.e. the coordinate space of the UITextView itself). However, this patch only works on iOS 18 where the draw method is called too many times, as the viewport changes. (I may have some other problems in my implementation, but I gave up on improving those, as this can't work reliably on all OS versions since the underlying framework isn't calling the method consistently.) Is this expected? What are our options for improving performance in these areas?
6
0
143
2w
Do we need to explicitly register all high-level interaction events for every widget in UIKit?
I have a question about how UIKit expects us to handle interaction events at scale. From what I understand so far: For UIControls (UIButton, UISwitch, UITextField, etc.), we explicitly register with addTarget(_:action:for:). For gestures, we add UIGestureRecognizer instances to views. For UIView subclasses, we can override touch methods like touchesBegan/touchesEnded. All of this must be done on the main thread, since UIKit isn’t thread-safe. Now here’s my main concern If I have a complex UI with hundreds or thousands of widgets, am I expected to perform these registrations individually for each widget and each high-level event (tap, long press, editing changed, etc.)? Or does UIKit provide a more centralized mechanism? In short: Is per-widget, per-event registration the “normal” UIKit approach, or are there best practices for scaling event handling without writing thousands of addTarget or addGestureRecognizer calls? Thanks!
Topic: UI Frameworks SubTopic: UIKit Tags:
3
0
91
2w
Summary of iOS/iPadOS 26 UIKit bugs related to UISearchController & UISearchBar using scope buttons
All of these issues appear when the search controller is set on the view controller's navigationItem and the search controller's searchBar has its scopeButtonTitles set. So far the following issues are affecting my app on iOS/iPadOS 26 as of beta 7: When the scopeBarActivation of UISearchController is set to .onSearchActivation, the preferredSearchBarPlacement of the navigationItem is set to .integratedButton, and the searchBarPlacementAllowsToolbarIntegration is set to false (forcing the search icon to appear in the nav bar), on both iPhones and iPads, the scope buttons never appear. They don't appear when the search is activated. They don't appear when any text is entered into the search bar. FB19771313 I attempted to work around that issue by setting the scopeBarActivation to .manual. I then show the scope bar in the didPresentSearchController delegate method and hide the scope bar in the willDismissSearchController. On an iPhone this works though the display is a bit clunky. On an iPad, the scope bar does appear via the code in didPresentSearchController, but when any scope bar button is tapped, the search controller is dismissed. This happens when the app is horizontally regular. When the app on the iPad is horizontally compact, the buttons work but the search bar's text is not correctly aligned within the search bar. Quite the mess really. I still need to post a bug report for this issue. But if issue 1 above is fixed then I don't need this workaround. When the scopeBarActivation of UISearchController is set to .onSearchActivation, the preferredSearchBarPlacement of the navigationItem is set to .stacked, and the hidesSearchBarWhenScrolling property of the navigationItem is set to false (always show the search bar), and this is all used in a UITableViewController, then upon initial display of the view controller on an iPhone or iPad, you are unable to tap on the first row of the table view except on the very bottom of the row. The currently hidden scope bar is stealing the touches. If you activate and then cancel the search (making the scope bar appear and then disappear) then you are able to tap on the first row as expected. The initially hidden scope bar also bleeds through the first row of the table. It's faint but you can tell it's not quite right. Again, this is resolved by activating and then canceling the search once. FB17888632 When the scopeBarActivation of UISearchController is set to .onSearchActivation, the preferredSearchBarPlacement of the navigationItem is set to integrated or .integratedButton, and the toolbar is shown, then on iPhones (where the search bar/icon appears in the toolbar) the scope buttons appear (at the top of the screen) the first time the search is activated. But if you cancel the search and then activate it again, the search bar never appears a second (or later) time. On an iPad the search bar/icon appears in the nav bar and you end up with the same issue as #1 above. FB17890125 Issues 3 and 4 were reported against beta 1 and still haven't been fixed. But if issue 1 is resolved on iPhone, iPad, and Mac (via Mac Catalyst), then I personally won't be affected by issues 2, 3, or 4 any more (but of course all 4 issues need to be fixed). And by resolved, I mean that the scope bar appears and disappears when it is supposed to each and every time the search is activated and cancelled (not just the first time). The scope bar doesn't interfere with touch events upon initial display of the view controller. And there are no visual glitches no matter what the horizontal size class is on an iPad. I really hope the UIKit team can get these resolved before iOS/iPadOS 26 GM.
1
1
101
2w
UITabBarController bottom accessory doesn't resize properly when horizontal size class changes from compact to regular
A bottom accessory view is set on the UITabBarController. When changing the window size either by dragging the resizing grip or when going to portrait mode, the accessory view shrinks down to the smaller width. When resizing the window to make it larger, the accessory view doesn’t resize to the full available width. During a workshop setup by Apple, folks from Apple told me that the view set as the content view of the UITabAccessory should not have its frame changed, either by using Auto Layout or by setting the frame. It seems logical since the view in the bottom accessory is supposed to resize accordingly to several factors, like when going inline inside the tab bar. Am I missing something? Maybe there is additional setup required not mentioned in the dedicated video. Feedback is FB19017330. It contains a sample project and videos demonstrating the issue. Reproduced on Xcode 26 beta 6 (17A5305f) I copy and paste the sample code that setups the bottom accessory for good measure. final class MiniPlayer: UIView { let label = UILabel() override init(frame: CGRect) { super.init(frame: frame) label.text = "Mini Player" label.numberOfLines = 0 label.textAlignment = .center addSubview(label) label.translatesAutoresizingMaskIntoConstraints = false NSLayoutConstraint.activate([ label.centerXAnchor.constraint(equalTo: centerXAnchor), label.centerYAnchor.constraint(equalTo: centerYAnchor) ]) } required init?(coder: NSCoder) { fatalError("init(coder:) has not been implemented") } } // MARK: - View Controller class ViewController: UIViewController { let rootTabBarController = UITabBarController() let miniPlayer = MiniPlayer() override func viewDidLoad() { super.viewDidLoad() let items: [UITab] = [ UITab(title: "Tab 1", image: UIImage(systemName: "archivebox.fill"), identifier: "tab-1") { _ in UIViewController() }, UITab(title: "Tab 2", image: UIImage(systemName: "books.vertical.fill"), identifier: "tab-2") { _ in UIViewController() }, UISearchTab { _ in UIViewController() } ] rootTabBarController.tabs = items rootTabBarController.view.backgroundColor = .secondarySystemBackground view.addSubview(rootTabBarController.view) rootTabBarController.view.translatesAutoresizingMaskIntoConstraints = false NSLayoutConstraint.activate([ rootTabBarController.view.leadingAnchor.constraint(equalTo: view.leadingAnchor), rootTabBarController.view.topAnchor.constraint(equalTo: view.topAnchor), rootTabBarController.view.trailingAnchor.constraint(equalTo: view.trailingAnchor), rootTabBarController.view.bottomAnchor.constraint(equalTo: view.bottomAnchor) ]) rootTabBarController.bottomAccessory = UITabAccessory(contentView: miniPlayer) } }
0
0
147
2w