Hi! I find your library very powerful and like it much more than SPIndicator. And I'd find it very nice to have a possibility to show Drops with multiline text. So this PR adds two properties to Drop struct to control numberOfLines of title and subtitle UILabels.

Due to a change in the latest Xcode beta, this no longer compiles as a SwiftPM dependency, even for a target that is not an extension. https://forums.swift.org/t/set-application-extension-api-only-on-a-spm-package/39333/8

It appears @available(iOSApplicationExtension, unavailable) now needs to be added in WindowViewController:44.

Error

SourcePackages/checkouts/Drops/Sources/WindowViewController.swift:44:45: 'shared' is unavailable in application extensions for iOS: Use view controller based solutions where appropriate instead.

Hey @omaralbeik,

amazing job with this library 💪

I've found an issue when using Drops with the SPM:

Possible fixes would be moving the Info.plist out of the Sources folder – as it's only used in the test-wrapper app, or explicitly excluding it from Package.swift target. I'd push a PR but I'm not really sure which approach you'd rather follow 😅

Hi! When presenting Drop above view controller that has preferredStatusBarStyle set to .lightContent there is a bug. Status bar turns to black while Drop is presented, and turn back to expected color (white) when dismissed. This PR fix this behaviour using UIWindow's private API override. There are several open radars related to this, but none of them is fixed. This fix is totally safe and we are using it in App Store without any issues for three years now.

Hey @omaralbeik,

is there any plan atm for supporting presenting DropViews at any level of the view hierarchy? I feel like it would make a lot of sense to decouple the actual presentation from the all WindowViewController "magic", especially for a better SwiftUI support, as it would allow to use Drops in a declarative way.

/// An optional `Drop` binding.
@State var drop: Drop?

// Something along the lines of…
var body: some View {
   Text("A random text")
      .frame(maxWidth: .infinity, maxHeight: .infinity)
      .drop($drop)
}

With a definition allowing for a Drops parameter, so that it could still reuse the same code, or even better, imho, just considering delayBetweenDrops (as the whole Binding thing would most likely deprecate the current queue system), or nothing at all (letting SwiftUI animation deal with that).

public extension View {
   /// Present a `Drop` view.
   ///
   /// - parameters:
   ///   - drop: An optional `Drop` binding. 
   ///   - drops: Some valid `Drops`. Defaults to `.shared`.
   /// - returns: Some `View`.
   drop(_ drop: Binding<Drop?>, with drops: Drops = .shared) -> some View {
      […]
   }

   // … OR …

   /// Present a `Drop` view.
   ///
   /// - parameters:
   ///   - drop: An optional `Drop` binding. 
   ///   - delayBetweenDrops: Some valid `TimeInterval`. Defaults to `0.5`.
   /// - returns: Some `View`.
   drop(_ drop: Binding<Drop?>, delayedBy delayBetweenDrops: TimeInterval = 0.5) -> some View {
      […]
   }
}

Of course this would require Drop to at least conform to Identifiable (either directly — unlikely due to the current deployment target, or just as an analogy), which would also give the user the ability to cancel any queued presenter "for free", using the imperative Drops (when dealing with UIKit directly).

/// Hide some drops.
/// - Parameter drops: `Drop`s to hide.
/// - Note: 
///    This is really just some "concept code". 
///    I tried to make it efficient instead of concise, 
///    but it's very much a draft.
public func hide<C: Collection>(_ drops: C) where C.Element == Drop {
    var identifiers = Set(drops.map(\.id))
    var shouldHideCurrent = false
    dispatchQueue.sync {
        queue.removeAll {
            let isRemoving = identifiers.remove($0.drop.id) != nil
            if !shouldHideCurrent { shouldHideCurrent = isRemoving && current?.drop.id == $0.drop.id }
            return isRemoving
        }
        guard shouldHideCurrent else { return }
        hideCurrent()
    }
}

I prefer to have overlays like this show in the opposite color scheme than the current one in use - this is to make sure it stands out against the background of the normal app views. So, feature request!

Hello and thank you for creating this! Is it possible for further customisation? Eg. using it for error messages (think on having a red background color etc)

When subtitle is long text the text size is too small that it is unable to be seen, when text is large drop size should be increased instead of decreasing the font size please check this.

• Fix a bug where showing a drop was not respecting the current status bar style
• Mark the library unavailable for app extensions
• Fix an accessibility bug where labels font size was not adjusting

Hi! This PR adds optional willShow parameter to Drops.show(_:) method to notify user that Drop is about to appear. I.e. it can be used to provide haptic feedback like it is done in SPIndicator, but since Drops are automatically enqueued, now it's impossible to say when you should send such feedback.

Thanks for creating great project.

I found that hiding speed of drops is too fast when position is .bottom. This PR makes hiding speed of bottom drops the same as top. Please close this PR if the current behavior is intentional.

| before | after | top (for reference) | | --- | --- | --- | | | | |