import type { ComponentType } from 'react';
/** The props this build asks of the picker, whichever platform draws it. */
export interface NativeDatePickerProps {
    value: Date;
    mode: 'date';
    display: 'inline' | 'calendar' | 'spinner';
    minimumDate: Date;
    maximumDate: Date;
    themeVariant?: 'light' | 'dark';
    onChange: (event: {
        type: string;
    }, date?: Date) => void;
}
export type NativeDatePicker = ComponentType<NativeDatePickerProps>;
/**
 * The picker, `null` when the peer is not installed, `undefined` while that
 * is still being decided.
 */
export type NativeDatePickerState = NativeDatePicker | null | undefined;
/**
 * The platform's own date picker, from the optional
 * `@react-native-community/datetimepicker` peer.
 *
 * Native by design decision — a hand-drawn calendar is not the control the
 * platform trains people on. The peer is optional so installing the SDK does
 * not force a native module on hosts that never take a fiat deposit; the
 * field falls back to a typed box when it is absent.
 *
 * The import is dynamic and inside a `try`, which is what makes the peer
 * genuinely optional: Metro treats a dependency whose import can reject as
 * optional and skips it at resolution rather than failing the bundle.
 */
export declare function useNativeDatePicker(): NativeDatePickerState;
/** How each platform draws a calendar: iOS inline, Android as its dialog. */
export declare const DATE_PICKER_DISPLAY: string;
/**
 * Whether the picker takes room on the screen. iOS draws it inline, so the
 * step must give up the keyboard's slot; Android opens a dialog over
 * everything and needs none.
 */
export declare const DATE_PICKER_IS_INLINE: boolean;
export declare function loadNativeDatePicker(): Promise<NativeDatePicker | null>;
//# sourceMappingURL=nativeDatePicker.d.ts.map